You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If fuse-overlayfs is available, it would make sense to use it instead of the kernel overlayfs. This would be especially useful on systems where overlayfs is not available for non-root users.
I wouldn't want to default to it for overhead reasons (FUSE has a ~7x overhead over VFS), but it should certainly be usable by flag. I can also imagine detecting a perm failure when setting up the overlay and falling back to fuse-overlayfs if it exists.
To do this right, we'll need to be kind of careful in our tests---we'll want to test all of the cases. Also, we should be careful to keep the mount logic clean, since things are getting complicated!
I agree that we should extend try to use fuse-overlayfs when a flag is given. I think detecting a failure and falling back to fuse sounds complicated so we could just suggest passing the --fuse flag if the default did not work due to an overlay permission issue.
I don't think the reentrancy would be so hard: try would start to take some extra arguments/environment variables that indicate what FS configuration it's currently trying. We'll need similar fallback logic to support various union filesystems for nested mounts (#67).
If fuse-overlayfs is available, it would make sense to use it instead of the kernel overlayfs. This would be especially useful on systems where overlayfs is not available for non-root users.
This is the strategy used by rootless podman (see https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md).
The text was updated successfully, but these errors were encountered: