On Fri, Sep 01, 2000 at 09:20:01AM -0500, Russell Cattelan wrote:
> Andi Kleen wrote:
> > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote:
> > > Is there any information on the 2 TBytes file system
> > > limitation in Linux which is also inherited by the
> > > linux port of xfs? What imposes this limitation?
> > > Are the current efforts aimed at removing this
> > > limitation? I hear ReiserFS has a 16 Terabyte
> > > file system size.
> > The 2TB limitation is caused by the interface between block drivers
> > and file systems. On 32bit machines a 32bit value is used to pass the
> > sector number, with the sector being in 512byte units. Limiting yourself
> > to 31bits is probably safer to protect against signedness bugs in the
> > driver.
> > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all
> > file systems and raw devices.
> > On 64bit systems the limit is higher, assuming there are no 32bit
> > limitations
> > in the driver.
> Also note the 16TB limit is true for all linux file systems at the moment.
> The block interface on linux indexes on the block size of the file system, in
> almost all cases it's the PAGE_SIZE aka 4k.
> 2^32 * 4096 / TB's = 16TB
Internally in ll_rw_block() it always scales down to 512 byte blocks, and
that is what the interface to the drivers uses. So it is always 2TB.
> Fixing this either requires changing linux to support 64bit inode numbers
> not terribly difficult but time consuming in that the linux community
> has to all agree as to what needs to be done, or change the way XFS
> deals with inode numbers. This does require some fundamental changes
> in XFS... up until this point we have made very few fundamental changes
> to XFS internals. Which as worked out very well since we know the code
> base is solid.
Linux needs to do it generally for the NFSv3 client anyways, so it may make
more sense to change Linux.