Sigh,
It was only speculations! When I tried to specify agcount and
agsize mkfs.xfs complained. It will not allow you to change both agcount and
agsize at the same time. Given one it choose the other based on the size
of the
file system.
Their is one other nob that can be turned with mkfs.xfs that will allow you to
create large file system and keep the inode size smaller then 32 bits. You
can increase the size of a inode with mkfs.xfs up to a maxima of 2048 so in
theory you could create a file systems up to 16 TB and keep the size of the
inodes to the 32 bit linux limit.
It turns that the real limitation is the 32 bit scoter offset in the disk
drivers. Russell Cattelan <cattelan@xxxxxxxxxxx> has pointed out that
LVM acts just like another disk driver so it has the same limitations. I
belive
that number is 2TB.
Bill Jones
At 09:18 AM 9/5/00 -0600, Davida, Joe wrote:
Is what Bill Jones is saying correct?
I am just starting on XFS, and dont
have enough familiarity with it's
architecture.
Cheers,
Joe
>-----Original Message-----
>From: William L. Jones [mailto:jones@xxxxxxxxxxxxxxxxxx]
>Sent: Friday, September 01, 2000 11:02 AM
>To: Steve Lord; William L. Jones
>Cc: cattelan@xxxxxxxxxxx; Davida, Joe; 'linux-xfs@xxxxxxxxxxx'
>Subject: Re: 2 Terabyte File System Size Limitation
>
>
>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
>
>
|