Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use fuse-overlayfs, where kernel overlay not available (--oci) #1727

Closed
Tracked by #1467
dtrudg opened this issue Jun 2, 2023 · 0 comments · Fixed by #1730
Closed
Tracked by #1467

Use fuse-overlayfs, where kernel overlay not available (--oci) #1727

dtrudg opened this issue Jun 2, 2023 · 0 comments · Fixed by #1730
Assignees

Comments

@dtrudg
Copy link
Member

dtrudg commented Jun 2, 2023

At present, the --oci mode relies on unprivileged overlay support in the kernel. This is not available on all systems. Introduced in mainline kernel 5.13. it has been backported to some distributions using older kernels, but not others.

We have some code that can check for unprivileged kernel overlay support here:

https://github.com/sylabs/singularity/blob/main/internal/pkg/util/fs/overlay/overlay_linux.go#L141

This check is currently used in native mode. Where unpriv kernel overlay is not supported, native mode will switch to an 'underlay' approach... in which many (many many) bind mounts are used, instead of an overlayfs mount, to assemble the combined view of the rootfs and --overlay source.

Underlay is complex and tied to the native runtime session layout. I don't think we want to implement it for --oci mode unless we fins a compelling reason to do so.

Instead, the OverlaySet code should use fuse-overlayfs (https://github.com/containers/fuse-overlayfs) if kernel unprivileged overlays are not available.

Implement an automatic check, prioritising kernel unprivileged overlay, but falling back to fuse-overlayfs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment