Re: [RFC][PATCH 00/13] overlayfs stable inodes

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Wed, Apr 19, 2017 at 06:17:15PM +0300, Amir Goldstein wrote:
> On Wed, Apr 19, 2017 at 6:01 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > On Wed, Apr 19, 2017 at 4:46 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> >> Well, if you are lucky you can run into a filesystem that exports
> >> a file handle of type FILEID_INO32_GEN, then you *know* you're
> >> good to go. ext* will do that and xfs that was forever mounted with
> >> -o inode32.
> >> Even with xfs -o inode64, it will not use the MSB ino bits unless
> >> you are in the exabytes fs sizes.

I think it only takes really big AGs for it to start using the >32 bit parts.

> >
> > Could filesystems export a max-ino property in their sb?  That would
> > help with doing this properly.
> >
> 
> Sounds reasonable, but as max-ino usually derived from filesystem size
> and filesystems can grow size online, you will need to query both the
> 'soft' ino limit (without growing fs) and the 'hard' ino limit.
> 
> Darrick,
> 
> Are there bits in GETFSMAP to provide this info?

Nope.  I suppose there could be a way to find out the theoretical
maximum inode number for a filesystem (statvfsx, etc.) but on the other
hand I can also see the other fs developers not wanting to expose that
information for fear that someone will start using the upper bits (inode
numbers should just be a 64-bit cookie we hand to users, right?) and
then they'll have to resort to all sorts of trickery to avoid breaking
things if they ever /do/ want to use those high bits that have been
claimed by someone else.

/me wonders what you're trying to accomplish?

--D