Re: fscache review comments, part 1

[Christoph Hellwig <hch@infradead.org>]

On Mon, Oct 02, 2006 at 10:39:00AM -0700, Andrew Morton wrote:
> On Mon, 02 Oct 2006 14:40:54 +0100
> David Howells <dhowells@redhat.com> wrote:
> 
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > 	Unfortunately there's a lot of broken userspace that can't deal
> > > 	with 64bit inode numbers, so you need to make the lod behaviour
> > > 	a mount option at least, probably even the default.  Given that
> > > 	we're going to run into problems like that it might make sense
> > > 	to make the option VFS-level instead of just in nfs.  (Note:
> > > 	XFS already has an option like that)
> > 
> > This really needs fixing quite urgently.  We've seen it break ld.so/libdl (and
> > other things, but dynamic loading is one of the major pains as it's not
> > entirely obvious).
> > 
> 
> Speaking of which..  I've been having struggling a bit with 
> 
> vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch
> nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch

Well, that's the two patches I've commented on above :)

> I don't have a good understanding of what the implications are for userspace.
> What are the risks and what are the advantages and what the level of urgency
> is behind those patches.

vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch is
perfectly fine and harmless, seems fine for 2.6.19.

nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch
is quite risky as I mentioned so I'd drop it for the time beeing - we
shouldn't put it in as long as we don't have a mount option for it.