Re: [PATCH] vfs: get_next_ino(), never inum=0

["J. R. Okajima" <hooanon05g@gmail.com>]

Andreas Dilger:
> The simplest solution is to just change get_next_ino() to return an
> unsigned long to match i_ino, instead of an int.  That avoids any
> overhead in the most common cases (i.e. 64-bit systems where I highly
> doubt there will ever be a counter wrap).
>
> We've also been discussing changing i_ino to be u64 so that this works
> properly on 32-bit systems accessing 64-bit filesystems, but I don't
> know where that stands today.

I agree that such wrap-around won't happen easily although it will
happen technically.
At the same time, I am not sure chaging u64 is safe to 32bit systems.
If nothing wrong happens, I agree get_next_ino() returns u64. Otherwise,
"if (unlikely(!inum)) inum++" is necessary.


> For 32-bit systems it would be possible to use get_next_ino() for the
> common case of inode numbers < 2^32, and only fall back to doing a
> lookup for an already-used inode in tmpfs if the counter wraps to 1.

How can tmpfs detect the wrap-around?
By storing the last largest inum locally?


> That would avoid overhead for 99% of users since they are unlikely
> to create more than 2^32 inodes in tmpfs over the lifetime of their
> system.  Even in the check-if-inum-in-use case after the 2^32 wrap,
> it is very unlikely that many inodes would still be in use so the
> hash lookup should go relatively quickly.

I agree that so many inodes won't live so long.

By the way, The reason I took the bitmap approach is to keep the inum
small numbers. That is my local requiment and I know it won't be
necessary for generic use.


J. R. Okajima