Open accelbread opened 1 year ago
@mgree Thoughts on checking if fuse-overlayfs exists then using it?
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).