Re: [PATCH v2 4/5] ovl: Support creation of whiteout files on overlayfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 21, 2023 at 3:55 PM Alexander Larsson <alexl@xxxxxxxxxx> wrote:
>
> On Mon, Aug 21, 2023 at 1:00 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Thu, 17 Aug 2023 at 13:05, Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> > >
> > > This is needed to properly stack overlay filesystems, I.E, being able
> > > to create a whiteout file on an overlay mount and then use that as
> > > part of the lowerdir in another overlay mount.
> > >
> > > The way this works is that we create a regular whiteout, but set the
> > > `overlay.nowhiteout` xattr on it. Whenever we check if a file is a
> > > whiteout we check this xattr and don't treat it as a whiteout if it is
> > > set. The xattr itself is then stripped and when viewed as part of the
> > > overlayfs mount it looks like a regular whiteout.
> > >
> >
> > I understand the motivation, but don't have good feelings about the
> > implementation.  Like the xattr escaping this should also have the
> > property that when fed to an old kernel version, it shouldn't
> > interpret this object as a whiteout.  Whether it remains hidden like
> > the escaped xattrs or if it shows up as something else is
> > uninteresting.
> >
> > It could just be a zero sized regular file with "overlay.whiteout".
> >
> > But we are also getting to the stage where the number of getxattr
> > queries on lookup could be a performance problem.  Or maybe not.  It
> > would be good to look at this aspect as well when adding xattr queries
> > to lookup.
>
> Wanting to avoid (as much as possible) the reading of more xattrs
> which would affect performance of every regular file was the reason
> for this particular implementation. I will do some more thinking and
> see if I can come up with an alternative approach.

I'd just like to add that, although the cost of getxattr is mostly fs
dependent, from my experience, the cost of several getxattr on one
file are usually amortized in the cost of the first getxattr on that file.

So while it is valuable to avoid any getxattr if possible, avoid an
extra getxattr is often less critical.
Again, this statement may not be accurate for all fs.

Thanks,
Amir.




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux