Re: [PATCH v3 0/6] Composefs: an opportunistically sharing verified image filesystem

[Gao Xiang]

On 2023/2/1 17:46, Alexander Larsson wrote:

...

> >                                    | uncached(ms)| cached(ms)
> > ----------------------------------|-------------|-----------
> > composefs (with digest)           | 326         | 135
> > erofs (w/o -T0)                   | 264         | 172
> > erofs (w/o -T0) + overlayfs       | 651         | 238
> > squashfs (compressed)	            | 538         | 211
> > squashfs (compressed) + overlayfs | 968         | 302
>
>
> Clearly erofs with sparse files is the best fs now for the ro-fs +
> overlay case. But still, we can see that the additional cost of the
> overlayfs layer is not negligible.
>
> According to amir this could be helped by a special composefs-like mode
> in overlayfs, but its unclear what performance that would reach, and
> we're then talking net new development that further complicates the
> overlayfs codebase. Its not clear to me which alternative is easier to
> develop/maintain.
>
> Also, the difference between cached and uncached here is less than in
> my tests. Probably because my test image was larger. With the test
> image I use, the results are:
>
>                                    | uncached(ms)| cached(ms)
> ----------------------------------|-------------|-----------
> composefs (with digest)           | 681         | 390
> erofs (w/o -T0) + overlayfs       | 1788        | 532
> squashfs (compressed) + overlayfs | 2547        | 443
>
>
> I gotta say it is weird though that squashfs performed better than
> erofs in the cached case. May be worth looking into. The test data I'm
> using is available here:

As another wild guess, cached performance is a just vfs-stuff.

I think the performance difference may be due to ACL (since both
composefs and squashfs don't support ACL).  I already asked Jingbo
to get more "perf data" to analyze this but he's now busy in another
stuff.

Again, my overall point is quite simple as always, currently
composefs is a read-only filesystem with massive symlink-like files.
It behaves as a subset of all generic read-only filesystems just
for this specific use cases.

In facts there are many options to improve this (much like Amir
said before):
  1) improve overlayfs, and then it can be used with any local fs;

  2) enhance erofs to support this (even without on-disk change);

  3) introduce fs/composefs;

In addition to option 1), option 2) has many benefits as well, since
your manifest files can save real regular files in addition to composefs
model.

Even if you guys still consider 3), I'm not sure that is all codebase
you will just do bugfix and don't add any new features like what I
said.  So eventually, I still think that is another read-only fs which
is much similar to compressed-part-truncated EROFS.


Thanks,
Gao Xiang


>    
> https://my.owndrive.com/index.php/s/irHJXRpZHtT3a5i