On Fri, Sep 14, 2007 at 06:03:49PM +0200, Christoph Hellwig wrote: > On Sat, Sep 15, 2007 at 01:22:16AM +1000, Greg Banks wrote: > > Not really a comment on your patches, but I got the original logic > > wrong here. The VFS_32BITINODES flag only affects newly allocated > > inodes and is no guarantee that any particular inode is < 2^32-1. > > It's possible for an unlucky user to perform a sequence of mounts > > and IO which results in large inode numbers despite the presence of > > that flag; we recently saw this happen by accident on a customer site. > > So the right thing to do is probably to check the inode number against > > (u32)~0. Unfortunately, given the current encoding scheme, you have to > > check both the inode and the parent inode, which complicates the logic. > > I'll see if we can do anything later on. But for now I'll leave it > as-is becaue this file will be merge hell anyway when both vfs removal > and exporting changes hit the tree.. Fair 'nuff. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. Apparently, I'm Bedevere. Which MPHG character are you? I don't speak for SGI. - 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
