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.
