xfs
[Top] [All Lists]

RE: 2 Terabyte File System Size Limitation

To: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
Subject: RE: 2 Terabyte File System Size Limitation
From: "Davida, Joe" <Joe_Davida@xxxxxxxxxx>
Date: Tue, 5 Sep 2000 09:18:04 -0600
Sender: owner-linux-xfs@xxxxxxxxxxx
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
>
>

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