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. 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. Thanks, Miklos -- 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
