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@xxxxxxxxxx> wrote: > > > Christoph Hellwig <hch@xxxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
