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

Support use of fuse-overlayfs #54

Open
accelbread opened this issue Jun 25, 2023 · 4 comments
Open

Support use of fuse-overlayfs #54

accelbread opened this issue Jun 25, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@accelbread
Copy link

accelbread commented Jun 25, 2023

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).

@ezrizhu ezrizhu added the enhancement New feature or request label Jun 25, 2023
@ezrizhu
Copy link
Collaborator

ezrizhu commented Jun 25, 2023

@mgree Thoughts on checking if fuse-overlayfs exists then using it?

@mgree
Copy link
Contributor

mgree commented Jun 25, 2023

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!

@angelhof
Copy link
Member

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.

@mgree
Copy link
Contributor

mgree commented Jun 26, 2023

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants