more then 4 billion files?

Nathan Schmidt nschmidt at gmail.com
Fri Feb 23 10:24:06 UTC 2007


Blake,

 From a practical perspective you'll probably need to split your  
MogileFS database instances (and hence trackers) to keep the indices  
(to say nothing of the file and file_on tables) a manageable size.  
Keep in mind your file_on table will have {mindevicecount}x more rows  
than you have files.

Here's some real-world data:

 > show table status;
...
for 'file':
	Data_length = 1,026,017,724
	Index_length = 1,170,308,096

for 'file_on':
	Data_length = 228,408,088
	Index_length = 792,318,976


Not really huge datasets but this is for only 14M files at  
mindevicecount=2. Tonight I'm adding millions more and bumping to   
mindevicecount=3 and I expect that footprint will rise accordingly.

In your case 4B = 28x more file entries so that's ~30Gb for just the  
'file' index -- keeping that whole index in core probably means  
either Really Big Servers or addressing multiple pools of MogileFS.

I'd hate to hit a hard wall with one 4B-entry table and _then_ decide  
it's time to fix the client side.

Regards,
-Nathan / PBwiki

On Feb 23, 2007, at 1:19 AM, Blake Golliher wrote:

> Any one using Mogile on more then 4 billion files?  If not, anyone
> think there's any design limitation on the maximum number of objects
> MogileFS will support?  Or is it just something someone has to test?
> Specifically in the user uploaded content space, written once, read
> for ever, and ever and ever.
>
> -Blake



More information about the mogilefs mailing list