On Wed, Aug 23, 2023 at 4:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Wed, 23 Aug 2023 at 16:43, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > If we do this, then both overlay.whiteout and overlay.xattr_whiteouts
> > xattrs will be xattrs that the overlayfs driver never sets.
> > It's a precedent, but as long as it is properly documented and encoded
> > in fstests, I will be fine with it. Not sure about Miklos.
>
> Firstly I need to properly understand the proposal. At this point I'm
> not sure what overlay.whiteout is supposed to mean. Does it mean the
> same as a whiteout (chrdev(0,0))? Or does it mean that overlayfs
> should not treat it as a whiteout, but instead transform that into a
> chrdev(0,0) for the top overlay to interpret as a whiteout? Or
> something else?
Both of these have been discussed, and I tried both in my two
alternative proposals in the other mail I just sent. Also, both
approaches could use the taint-the-directory xattr approach amir
proposed here.
I think the overlay.whiteout transforms to chrdev(0,0) approach is
better, because that will allow the resulting unescaped whiteout to be
used by both regular and userxattr overlay mounts.
I'll have a go at combining the transform approach with a directory
xattr, because that could use regular files that get transformed to
whiteouts, which means it could also work with user.overlay.whiteout
xattrs.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
