Additional Layer Store no longer works for layers without TOC Digest annotations

[GerrySeidman]

Background: The AuriStor's Additional Layer Store (ALS) FUSE driver simply mounts layer 'diff' directories directly from the the AuriStorFS distributed file system (based on image names and layer digests). The AuriStor ALS FUSE driver currently works with unmodified OCI images. It does not require nor does it use any TOC Digest or index file (as with stargz).

The AurIStorFS ALS FUSE driver currently services Layer content relative to the Layer Digest:

<ALS Root>/<base64(imageName)>/<LayerDigest>/{info,diff,use,blob}

First Occurance: As of containers/image 5.31 (Podman 5.1), the ALS Semantics changed such that there is no longer an ALS Code path for images without a TOC Digest Annotation (containerd.io/snapshot/stargz/toc.tocJSONDigestAnnotation or containers/storage/pkg/chunked/internal/compression.ManifestChecksumKey or "containerd.io/snapshot/stargz/toc.digest" / "io.github.containers.zstd-chunked.manifest-checksum" respectively).

image/storage/storage_desc.go, tryReusingBlobAsPending() now requires options.TOCDigest != "" in order to execise/leverage ALS in its code path:

        containers/image v53.0: if options.SrcRef != nil 
        containers/image v5.31: if options.SrcRef != nil && options.TOCDigest != "" && options.LayerIndex != nil 

Other changes: The ALS Semantics seems to now be that, for those images with TOC annotations, ALS now expects the FUSE driver to service the layer based on the TOC Digest

<ALS Root>/<base64(imageName)>/<TOCDigest>/{info,diff,use,blob}

Note: I did not participated in any of the design discussions around these changes to ALS, but it appears that ALS is being narrowed towards support of zstd:chunked, composefs, and fs-verity.

Issue: If the intention is to continue allowing ALS plugins (such as the AuriStorFS ALS) to be able to support unmodified OCI Images (ie without TOC annotations), then this is a bug that was introduced in image:5.31 and storage:1.54

Request: Some clarity on the intended ALS paths and path semantics that an ALS Fuse driver should be servicing (going forward) would be appreciated. I could then modify the AuriStorFS ALS Fuse driver to service layers appropriately. - Thanks

Note: While our current AuriStorFS ALS implementation uses a FUSE driver, our plan is to ultimately provide ALS support natively from the AuriStorFS Kernel module (along with also adding fs-verity support to AuriStorFS)