On Fri, Jun 16, 2023 at 11:28 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Fri, Jun 16, 2023 at 11:39 AM Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> >
> > On Fri, Jun 16, 2023 at 10:12 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > >
> > >
> > > > I don't believe this format will actually need to change much.
> > > > However, I do agree
> > > > with the general requirement for *some* ability to move forward with
> > > > this format,
> > > > so I'm gonna go with a single version byte.
> > > >
> > >
> > > I disagree.
> > > If you present a real life use case why that really matters
> > > then I can reconsider.
> >
> > I disagree, but I'll add them.
> >
>
> Let's ask for a 3rd opinion.
> don't add them for now, unless Miklos says that you should.
I added them to the branch anyway for now. However, if we're going
full header + flags anyway, I wonder if we really need the
"overlay.digest" xattr at all? We could just put the header + optional
digest in the "overlay.metacopy" xattr, and then just read/store one
xattr. Right now metacopy is zero size, but adding some data to it
would not break ovl_check_metacopy_xattr() in older kernels.
Basically, during the lookup we get the metacopy xattr anyway, and
when we do we could record in a flag that there is a digest in it,
then during open we don't have to look for a separate digest xattr,
just re-load the metacopy xattr if the flag is set. With this in place
we can also easily add other flags to overlay.metacopy, which imho
makes a ton more sense than adding flags to overlay.digest.
I'll have a look at this.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
