Re: [PATCH 2/3] fs: inode: Add API to retrieve global next ino using full ino_t width

[Amir Goldstein]

On Fri, Dec 27, 2019 at 4:30 PM Chris Down <chris@xxxxxxxxxxxxxx> wrote:
>
> We can't just wholesale replace get_next_ino to use ino_t and 64-bit
> atomics because of a few setbacks:
>
> 1. This may break some 32-bit userspace applications on a 64-bit kernel
>    which cannot handle a 64-bit ino_t -- see the comment above
>    get_next_ino;
> 2. Some applications inside the kernel already make use of the ino_t
>    high bits. For example, overlayfs' xino feature uses these to merge
>    inode numbers and fsid indexes to form a new identifier.
>
> As such we need to make using the full width of ino_t an option for
> users without being a requirement.
>
> This will later be used to power inode64 in tmpfs, and can be used
> elsewhere for other filesystems as desired.
>

Unless I am missing something, I think the fact that get_next_ino()
is a global counter was short sighted to begin with or it was never
intended to be used for massive usage fs.

So I think that introducing another global counter to be used
intentionally for massive usage is a mistake.

I think tmpfs should be converted to use a per-sb ino allocator.
When it's per-sb allocator, implementing the option if ino numbers
are 32bit or 64bit per instance won't be a problem.

Thanks,
Amir.