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@xxxxxxxxxx> wrote: > > On Wed, Apr 19, 2017 at 4:46 PM, Amir Goldstein <amir73il@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
