Re: [PATCH v2] ovl: require xwhiteout feature flag on layer roots

From: Amir Goldstein <amir73il@gmail.com>
To: Alexander Larsson <alexl@redhat.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	linux-unionfs@vger.kernel.org,  linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] ovl: require xwhiteout feature flag on layer roots
Date: Mon, 22 Jan 2024 13:30:43 +0200	[thread overview]
Message-ID: <CAOQ4uxiYQp_1ftooE0z6MR4iqjf392QpaaptgRwT4ogaefo8aw@mail.gmail.com> (raw)
In-Reply-To: <0473f5389dd1ada08c73479612a4e054c8023d94.camel@redhat.com>

> > Alex,
> >
> > As you can see, I posted v3 with an alternative approach that would
> > not
> > require marking all possible lower layer roots.
> >
> > However, I cannot help wondering if it wouldn't be better practice,
> > when
> > composing layers, to always be explicit, per-directory about whether
> > the
> > composed directory is a "base" or a "diff" layer.
> >
> > Isn't this information always known at composing time?
>
> Currently, composefs images are not layered as such. They normally only
> have one or more lowerdata layers, and then the actual image as a
> single lowerdir, and on top of that an optional upper if you want some
> kind of writability.
>
> But, when composing the composefs the content of the image is opaque to
> us. We're just given a directory with some files in it for the image.
> It might contain some other lowerdirs, but the details are not know to
> us at compose time.
>

Got it, though I may need you to explain this again to me next time ;)

If we were to change the tools that pack/extract overlayfs images to
mark directories more explicitly, we would need to change other tools,
not composefs.

composefs has no knowledge of the fact that it is packing an overlayfs
image, until it is asked to pack a whiteout or a file/dir that happens to
have an overlay.* xattr, but lower layers do not typically have to contain
files/dir with overlay.* xattrs.

> However, I think it may make sense to be able to mark non-lowest-layer
> directories with either n or y.

There is nothing stopping you from setting opaque=y on lowest layer dirs
or setting opaque=n on merge dirs when packing composefs.
Old kernels will not be bothered by these marks.

However, I forgot about the consideration of xattr lookup performance that
was the drive for erofs xattr bloom filter support.

I guess erofs will pack much smaller without those explicit annotations and
getxattr(opaque) will have better performance for no xattr case then with
opaque=n.

Thanks,
Amir.