At 09:20 AM 9/1/00 -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
> 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
> 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
XFS has additional problems with inode numbers overflowing the
standard 32bit container once the file system its self goes over 2TB.
I was wondering about that. It seem like you should be able to control
this with mkfs.xfs by setting agcont and setting the
agsize instead of letting mkfs.xfs set them. I don't think that many people
need a file system that can contain a billion files. Just a few
hundred million will due. The only down side in doing this
is that the inode info may not be splattered across all of the file system
like it would if you used the mkfs.xfs defaults.
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.
It is unclear as the best path at this point.
It is one of the things to fix in one of the near future releases.
For the moment we are concentrating on getting our first Beta