[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 and 64 bit addressing

On Fri, Jul 06, 2001 at 11:44:51PM -0400, Iain Campbell wrote:
> Dear List People:
> I am doing some comparisons of different fs's and need to know where ext3 
> stands in terms of 64 bit addressing. XFS and JFS claim to be full 64 bit 
> systems (though are there not still kernel limitations that would, for the 
> time being, reduce the ability to use a full 64 bits?), what about ext3??

On a per-file basis, ext3 has a 41 bit file-size (number of blocks
used) limitation, caused by the fact that i_blocks in the inode is a
32 bit value which is addressed in 512 byte blocks.  This isn't a big
deal at the moment, given that limitations in the linux buffer cache
limit have the same limitation on the total filesystem size, at least
on 32-bit systems.  Fixing this limitation is pretty trivial kernel
patch and minor format change, and that would give us a 44 bit total
file size without much if any sweat. 

In terms of total addressable file size (assuming a sparse file), the
limits are caused by the current limits of using a 4k blocks size and
the number of blocks which can be addressed by using the triple
indirection block.  This turns into (10 + 10 + 10 + 12) = 42 bits,
assuming a 4k block size.  (It's a little bit more than that, since
you can also store 2^22 bytes using the double indirection block,
et. al., but for order of magnitude calculations it's basically 42

>From a total filesystem standpoint, we're using 32 bit block pointers,
which assuming the use of 4k (12 bits) block sizes, gives us a 44 bit
limitation for the total filesystem.

So the limitations of ext2 are somewhere between 41 and 44 bits,
depending on how you count things.  Given that 41 bits is 2 Terabytes,
and 44 bits is 16 Terabytes, it's not really a practical limitation at
this point.  

It's not clear, by the way, how often you really *want* to create
filesystems quite this huge.  Even on an EMC Symmetrix, for example,
which can support pedabytes of information today (if you don't mind
the multi-million dollar price tag), the typical usage pattern is to
create thousands and thousands of smaller filesystems, just simple for
easier manageability by the system administrators.  Hence when we
talked to EMC about what they needed most from Linux to better support
EMC boxes, the answer was not filesystems that could support
gargantuan disk sizes, but rather a SCSI subsystem that could support
thousands of LUN's....

						- Ted

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]