-
Notifications
You must be signed in to change notification settings - Fork 68
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
Support use of fuse-overlayfs #54
Comments
@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: |
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: