Messages in this thread | | | From | Amir Goldstein <> | Date | Fri, 27 Dec 2019 17:32:50 +0200 | Subject | Re: [PATCH 2/3] fs: inode: Add API to retrieve global next ino using full ino_t width |
| |
On Fri, Dec 27, 2019 at 4:30 PM Chris Down <chris@chrisdown.name> 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.
| |