xfs
[Top] [All Lists]

Re: 2 Terabyte File System Size Limitation

To: Steve Lord <lord@xxxxxxx>, "William L. Jones" <jones@xxxxxxxxxxxxxxxxxx>
Subject: Re: 2 Terabyte File System Size Limitation
From: "William L. Jones" <jones@xxxxxxxxxxxxxxxxxx>
Date: Fri, 01 Sep 2000 13:02:04 -0500
Cc: cattelan@xxxxxxxxxxx, "Davida, Joe" <Joe_Davida@xxxxxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <200009011644.LAA30940@xxxxxxxxxxxxxxxxxxxx>
References: <Message from "William L. Jones" <jones@xxxxxxxxxxxxxxxxxx> <4.2.0.58.20000901112356.022a8de0@xxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
At 11:44 AM 9/1/00 -0500, Steve Lord wrote:

> >
> >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.
>
>


The problem is not the number of inodes the system will allow you to create,
it is where they are created. An XFS inode number is actually a disk address,
once the filesystem goes beyond the 2Tbyte limit inodes can have addresses
which are beyond this boundary and hence over flow the 32 bit inode field.

At the moment there is no way of restricting inodes to specific allocation
groups, but I suppose it would be possible to do this. In fact it might be
a simpler solution than anything else. The consequences are :

1. moving an existing filesystem from Irix will still potentially leave
   us with inodes beyond the boundary.

2. it will change the distribution of inodes in the filesystem, which will
   in turn change how data is distributed. There is a danger that the first
   2 Tbytes would have to become fairly full and hence potentially fragmented
   before much data made it into the rest of the filesystem. This will take
   some thinking about.

Steve




It really is very simple.    XFS  just the inode shifted down
by the by the log2(number of inodes per disk block)+log(agsize) to find
the ag group that the inode is in.

The the maxima  inode is just:

   agcount<<log2(number of inodes per disk block)+log(agsize in blocks)

Inodes on xfs are restricted to a specific allocation group.   Each
allocation group can only contain agsize/(inodes per disk block) inodes.

For any xfs file system with mkfs.xfs we can choose agcount and agsize to insure that that the maxium inode less then 32 bits for any size of an xfs file system.

Like I said the only draw back is that the inode regions will not cover
be spread over all the disk systems which is what mkfs.xfs does by its
chose of agcount and agsize.

It looks like you should be able to make 16TB xfs file system with lVM,
if LVM really allows you to address 16TB of disk in a partation,
on linux so long as you don't use the mkfs.xfs defaults.

I could live with that.

Bill Jones



<Prev in Thread] Current Thread [Next in Thread>