On Mon, Nov 6, 2017 at 3:57 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Mon, Nov 6, 2017 at 12:45 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Mon, Nov 6, 2017 at 11:35 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > >>> And I'm still hoping we can get some infrastructure for partitioning >>> the ino space (i.e. filesystem can report that it will only use N bits >>> from the available 64). This would allow properly solving the >>> non-samefs case without adding hacks. >>> >> >> Oh! there is a ridiculously simple way for some file systems to know >> that they are using 32 bit inodes. >> We already call ovl_can_decode_fh() for upper and all lower layers. >> All we need to do is actually encode the layer directory and check >> returned fh_type. >> >> If fh_type is FILEID_INO32_GEN, bingo! >> That turns out to be true to all file systems that use the default >> implementation of .encode_fh, including the ext* family, squashfs >> and more. > > That's good. However testing FILEID_INO32_GEN is not particularly > reliable since that constant is defined as "1" and AFAIR there are > other uses of "1" as type, just not with this name. And nothing > guarantees that all those uses are for 32bit inode numbers, although > that may be the case. > Right... although for most fs I mentioned, default .encode_fh *is* in fact a guaranty for 32bit inodes, so we can start with that and add explicit number of bits to super block later. > I'd be more happy with an explicit bit count in struct super_block > indicating the number of bits in use. > > Such an interface wouldn't limit filesystem implementors in any way. > They'd just be more flexibly declare the needs they have. > > Also there is possibly a usecase for a large fs (non 32-bit inum) as > overlayfs upper layer. I would guess it wouldn't be too difficult to > add an "inumbits=N" parameter to mkfs.xfs for that case. > Cannot set inumbits, because they are already determined by fs geometry (MSB bits are AG #). The good news is that you can always know the max inumbits of any existing xfs, so it would be possible for admin to mount overlay with mount option upperinumbits=. The bad news is that I think any xfs can potentially be grown to use all inode bits, so it is unlikely that xfs will be willing to make any inumbits commitment in super block besides the already supported case of inode32 mount option. Amir. -- 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
