Game out a plan for a 1.1 format

[cgwalters]

Let's assume 1.0 is released, and we discover something like a notable performance issue with the 1.0 format. Or maybe it's actually broken in an important corner case on big-endian (s390x) - something like that.

Say this is important enough to do a 1.1.

I think the way this would need to work is basically we add support for e.g. --format=1.1 to the CLI/API - and then we generate both digests.

We need to think through and verify a scenario like this would work:

• Build server is updated with composefs 1.1 support
• Client system (e.g. ostree/container tooling/RAUC/whatever) only has 1.0 support
• Client fetches metadata (OCI image, whatever) that has both digests
• Client ignores the 1.1 digest, synthesizes a 1.0 format, and successfully verifies it against the 1.0 digest
• Client later than updates to tooling (podman/ostree/RAUC) that supports 1.1
• Client synthesizes a 1.1 EROFS, and verifies using that digest

Right?

[cgwalters]

It may actually be worth adding a stub 1.1 format now that has a trivial change as a hidden option just to really test things out.

[alexlarsson]

There is already a uint32_t version in struct lcfs_write_options_s for this particular reason. But you're right, we should plumb it to the CLI and actually test it.

[alexlarsson]

If we wanted a stupid optional feature we could have one that skips the 00-ff whiteouts in the image. That means its only going to work well (i.e. the basedir would not be visible) with kernels that have data-only overlayfs layers, but for those it would be more efficient.

[allisonkarlitskaya]

Other potential wishlist item for a trivial change to make things more efficient: more aggressive list of xattr prefixes. We should really have "prefixes" for the complete length of all of the overlayfs xattrs we output.

[alexlarsson]

The use of custom prefixes would be nice, but it does bump up the kernel requirements to 6.4.