Andi Kleen wrote:
> 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.
So I haven't gone and actually looked at code but given the only way to get to
16TB is through a volume manager, the process or re-mapping requests
will bring any individual device under the 2^40 limit but still allow indexing
the ll_rw_block level up to 16TB.
I'll have to go look to verify this.
> > 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.
That is what we assuming will happen thus we have been punting on this issue
until things are worked out.