[lkml]   [2019]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 <> 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.


 \ /
  Last update: 2019-12-27 16:34    [W:0.034 / U:25.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site