On Tue, Aug 22, 2023 at 7:19 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 22 Aug 2023 at 17:57, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > On Tue, Aug 22, 2023 at 6:43 PM Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Aug 22, 2023 at 5:31 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > > > FWIW, there is also DT_WHT that was defined and never used.
> > > > But that is just an anecdote.
>
> Overlay could be the first filesystem to set DT_WHT in its readdir.
> I wouldn't mind if others would follow suit, but it's not a high
> priority thing.
>
>
>
> > > >
> > > > Regarding the issue of avoiding getxattr for every dirent.
> > > > Note that in readdir, dirent that goes through ovl_cache_update_ino()
> > > > calls lookup()/stat() on the overlay itself, so as long as ovl_lookup()
> > > > will treat overlay.whiteout file as a whiteout, the code
> > > > /* Mark a stale entry */
> > > > p->is_whiteout = true;
> > > > will kick in and do the right thing for readdir wrt cleaning up
> > > > lower entries covered with whiteouts, regardless of DT_CHR.
> > >
> > > We don't want to treat this file as a whiteout though. We want it to
> > > be exposed as a regular file that looks like a whiteout marker file
> > > (i.e. char dev 0,0). Or am I missing something?
> > >
> >
> > Not sure if you really need to emulate chardev(0,0) at all.
> >
> > Suppose that you just define a new way to express a whiteout -
> > an empty regular file with xattr overlay.whiteout.
>
> Oh, you mean overlay.overlay.whiteout on realfile, which gets turned
> into overlay.whiteout on bottom overlay, which gets interpreted as a
> whiteout on top overlay?
>
> I suppose that would work too, but it's a bit of a layering violation.
>
I proposed to look at the two features independently:
1. Nesting of overlayfs xattrs (patch 3/5)
2. Alternative format for whiteout (overlay.whiteout) that can be used
by container tools converting OCI/tar images to overlayfs images
Together, they provide a solution to Alexander's use case.
IIUC, the way this is intended to work is that mkfs.composefs
is running inside a container, whose work directory is overlayfs
and it composes some lower layers on that host mounted overlayfs.
mkfs.composefs composes layers with overlay.{metacopy,whiteout,redirect}
xattrs (up to here it is standard mkfs.composefs) and because those layers
are stored in overlayfs, the xattrs are stored in the host fs as
overlay.overlay.*.
I hope I got the use case correctly?
Why is that a layering violation?
Thanks,
Amir.
