On Thu, Sep 12, 2013 at 08:33:28PM +0100, Al Viro wrote: > i_ino use is entirely up to filesystem; it may be used by library helpers, > provided that the choice of using or not using those is, again, up to > filesystem in question. With more and more filesystems using large inode numbers I'm starting to wonder if this still makes sense. But given that it's been this way for a long time we should have more documentation of it for sure. > NFSD has no damn business looking at it; library > helpers in fs/exportfs might, but that makes them not suitable for use > by filesystems without inode numbers or with 64bit ones. > > The reason why it's there at all is that it serves as convenient icache > search key for many filesystems. IOW, it's used by iget_locked() and > avoiding the overhead of 64bit comparisons on 32bit hosts is the main > reason to avoid making it u64. > > Again, no fs-independent code has any business looking at it, 64bit or > not. From the VFS point of view there is no such thing as inode number. > And get_name() is just a library helper. For many fs types it works > as suitable ->s_export_op->get_name() instance, but decision to use it > or not belongs to filesystem in question and frankly, it's probably better > to provide an instance of your own anyway. Given that these days most exportable filesystems use 64-bit inode numbers I think we should put the patch from Bruce in. Nevermind that it's in a slow path, so the overhead of vfs_getattr really doesn't hurt. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
