Re: [PATCH v2 01/18] overlay: implement fsck utility

[Vivek Goyal <vgoyal@redhat.com>]

On Thu, Dec 14, 2017 at 05:43:00PM +0200, Amir Goldstein wrote:
> On Thu, Dec 14, 2017 at 5:21 PM, Vivek Goyal <vgoyal@redhat.com> 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.

User still need to worry about 3 (or more) directories for spec file
creation. And for furture mounts/remount spec file can be used. Not
sure how it will work with changing spec file etc.

> 
> > 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.

Ok. I personally like the idea of storing required info in an xattr in upper
and not having to worry about managing spec file for overlay mount. But that's
just me. :-)

Vivek