Re: [PATCH 3/3] shmem: Add support for using full width of ino_t

[Chris Down]

Amir Goldstein writes:
> On Fri, Dec 27, 2019 at 4:30 PM Chris Down <chris@xxxxxxxxxxxxxx> wrote:
> > The new inode64 option now uses get_next_ino_full, which always uses the
> > full width of ino_t (as opposed to get_next_ino, which always uses
> > unsigned int).
> >
> > Using inode64 makes inode number wraparound significantly less likely,
> > at the cost of making some features that rely on the underlying
> > filesystem not setting any of the highest 32 bits (eg. overlayfs' xino)
> > not usable.
>
> That's not an accurate statement. overlayfs xino just needs some high
> bits available. Therefore I never had any objection to having tmpfs use
> 64bit ino values (from overlayfs perspective). My only objection is to
> use the same pool "irresponsibly" instead of per-sb pool for the heavy
> users.

Per-sb get_next_ino is fine, but seems less important if inode64 is used. Or is 
your point about people who would still be using inode32?

I think things have become quite unclear in previous discussions, so I want to 
make sure we're all on the same page here. Are you saying you would 
theoretically ack the following series?

1. Recycle volatile slabs in tmpfs/hugetlbfs
2. Make get_next_ino per-sb
3. Make get_next_ino_full (which is also per-sb)
4. Add inode{32,64} to tmpfs

To keep this thread as high signal as possible, I'll avoid sending any other 
patches until I hear back on that :-)

Thanks again,

Chris