Re: [LSF/MM/BFP TOPIC] Composefs vs erofs+overlay

[Alexander Larsson <alexl@redhat.com>]

On Mon, Mar 6, 2023 at 5:17 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:

> >> I tested the performance of "ls -lR" on the whole tree of
> >> cs9-developer-rootfs.  It seems that the performance of erofs (generated
> >> from mkfs.erofs) is slightly better than that of composefs.  While the
> >> performance of erofs generated from mkfs.composefs is slightly worse
> >> that that of composefs.
> >
> > I suspect that the reason for the lower performance of mkfs.composefs
> > is the added overlay.fs-verity xattr to all the files. It makes the
> > image larger, and that means more i/o.
>
> Actually you could move overlay.fs-verity to EROFS shared xattr area (or
> even overlay.redirect but it depends) if needed, which could save some
> I/Os for your workloads.
>
> shared xattrs can be used in this way as well if you care such minor
> difference, actually I think inlined xattrs for your workload are just
> meaningful for selinux labels and capabilities.

Really? Could you expand on this, because I would think it will be
sort of the opposite. In my usecase, the erofs fs will be read by
overlayfs, which will probably access overlay.* pretty often.  At the
very least it will load overlay.metacopy and overlay.redirect for
every lookup.

I guess it depends on how the verity support in overlayfs would work.
If it delays access to overlay.verity until open time, then it would
make sense to move it to the shared area.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl@redhat.com         alexander.larsson@gmail.com