On Thu, Dec 14, 2017 at 5:21 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Thu, Dec 14, 2017 at 04:33:21PM +0200, Amir Goldstein wrote: ... >> Other fsck do not have this problem. >> They only need blockdev as input. >> Which leads me to an idea I have been wondering about for the overlayfs >> utilities - a specification file, e.g.: >> >> # create dirs and write their path to a spec file: >> mkfs.overlay -ometacopy=on,lowerdir=... myovl.spec >> # mount overlay using mount.overlay helper: >> mount -t overlay myovl.spec /ovl >> # fsck with just one configuration that is consistent with mkfs and mount: >> fsck.overlay -n myovl.spec >> >> The specification file can also determine the backward incompatible >> features of the overlay, for example, if user sets -metacopy=on during mkfs >> mount.overlay helper will refuse to mount with kernel that does not >> support metacopy. The reason we CAN do that with spec file is because spec >> file determines that overlay was born with metacopy feature enabled. >> It is not the same an overlay that was once mounted with metacopy=on and >> then we don't allow it to mount with an old kernel. > > So why not store this information in an xattr on upper/ (instead of spec > file) and then overlay specific helpers could parse it do same thing. I Maybe. > mean otherwise user space has to worry about storing and finding out > right foo.ovl.spec file for any mount/unmount or other operations. From > a user's perspective, I would be glad if I don't have to worry about > managing another spec file per overlay mount. > That's one way of looking at it, another way to look at it would be now user doesn't need to worry 3 directories but just one file. Anyway the spec file is meant to be an abstraction layer, not a replacement for using existing mount options. > This will only work if kernel is old but tools are still new. Not sure > how many a times people run with this configuraiotion. > The major benefit of starting fresh with user tools and spec file is that we can start by checking features compatibility from day 1. You can think of a spec file as a declaration from admin that this overlay is never going to be mounted on a kernel that doesn't support the spec file required features. It's fine if the "file" end up being stored in "features" or "spec" xattr on upper dir. That is an implementation detail and we can actually make this a user choice and user tools can both accept a spec file as input or look for the xattr in upper dir. Amir. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
