On Wed, Oct 04, 2006 at 03:18:21PM +0100, David Howells 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 problem doesn't just apply to NFS. It applies to any filesystem that can > generate 64-bit inode numbers - which includes Ext3, I believe - so not > applying the NFS patch doesn't really solve your problem (Al Viro asked me for > examples of that, btw) and leaves my problem unsolved. As you mention in your next mail ext3 is not affected. XFS for example is, that's why it has a 32bit inode numbers only mount option already. > I think any solution has to apply at the VFS level or higher. I'm not sure Al > agrees though. I think we have to do one of the following: > > (1) Turn on inode number compression (which tries to hide the problem). > > (2) Give an error to stat and getdents if the inode number can't be > represented by 32-bits. > > And I think we're going to do this, that we need to do this on a per-superblock > basis or on a per-system basis, and I think it should be _off_ by default. It > might also be possible to do it on a per-process level, but I suspect that'd be > too much effort. This definitly should be on a per-superblock basis, aka the mount option I suggested above. I don't think an actual scheme to deal with the inode numbers at the VFS level makes sense, what I meant was only to do a vfs-level mount option (numerical) instead of a per-filesystem one. Al commented he doesn't like that. He also think we should give the 64bit inode numbers a try, so I'd say: o add an inode32 option for nfs that mirrors the XFS option o turn it off by default in -mm and see what goes boom - 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
