Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

[Matthew Wilcox <matthew@wil.cx>]

On Tue, Nov 14, 2006 at 03:22:08PM -0500, Jeff Layton wrote:
> 1) on filesystems w/o permanent inode numbers, i_ino values can be
> larger than 32 bits, which can cause problems for some 32 bit userspace
> programs on a 64 bit kernel.
> 
> 2) many filesystems call new_inode and assume that the i_ino values they
> are given are unique. They are not guaranteed to be so, since the static
> counter can wrap.
> 
> 3) after allocating a new inode, some filesystems call iunique to try to
> get a unique i_ino value, but they don't actually add their inodes to
> the hashtable, and so they're still not guaranteed to be unique.

I agree with these problems, but I liked your earlier approach to fixing
them.  I don't particularly like the idr approach because, as you say,
it will reuse numbers rapidly.

Why is it these filesystems don't add their inodes to the hashtable?
Might that not be a more profitable approach to fixing this problem?