xfs
[Top] [All Lists]

Re: 2 Terabyte File System Size Limitation

To: Steve Lord <lord@xxxxxxx>
Subject: Re: 2 Terabyte File System Size Limitation
From: "Andi Kleen" <ak@xxxxxxx>
Date: Sat, 2 Sep 2000 02:45:35 +0200
Cc: cattelan@xxxxxxxxxxx, "Davida, Joe" <Joe_Davida@xxxxxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <200009011442.JAA28903@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Fri, Sep 01, 2000 at 09:42:42AM -0500
References: <cattelan@xxxxxxxxxxx> <200009011442.JAA28903@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Fri, Sep 01, 2000 at 09:42:42AM -0500, Steve Lord wrote:
> >> >  > 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.
> >>  
> 
> I still think making the contents of the NFS file handle opaque to NFS
> itself is a better way to go. It has a length field, and the file systems
> can do the best they can with the space available.

That is being planned (e.g. see the patch set from Neil Brown) 

I was talking about the v3 client not the server, sorry for being unclear.
For it the file handle is opaque anyways. It just has to support 64bit
fileid and readdir cookies, upto userland.

-Andi

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