Re: why is i_ino unsigned long, anyway?

[Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html