On Fri, Jun 16, 2023 at 2:33 PM Alexander Larsson <alexl@xxxxxxxxxx> wrote: > > 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 think that is a wonderful idea. I like it a lot. Thanks, Amir.
