-
Notifications
You must be signed in to change notification settings - Fork 42
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
mount: support FUSE helper #40
base: main
Are you sure you want to change the base?
Conversation
When m.Type starts with either fuse. or fuse3, the mount helper binary mount.fuse or mount.fuse3 is executed. Similar to the changes made in containerd: > This is expected to be used by fuse-overlayfs plugin: https://github.com/AkihiroSuda/containerd-fuse-overlayfs > > Motivation > > The purpose of the containerd fuse-overlayfs snapshotter plugin is to provide > OverlayFS functionality for rootless mode without depending on the Ubuntu/Debian > kernel patch. > Although fuse-overlayfs provides shiftfs functionality and supports CRFS plugin, > these functionalities are not planned to be supported by the containerd fuse-overlayfs Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Opening as draft for now, depending on how much sense it will make to replace the mounting part that's in containerd with moby/sys as well. Containerd also has some mount/unmount code for Windows, but that may be very container specify, so TBD if we want to keep this repository as "generic" or "container specific" |
|
||
func unmountBare(target string, flags int) error { | ||
return unix.Unmount(target, flags) | ||
} | ||
|
||
// fuseSuperMagic is defined in statfs(2) | ||
const fuseSuperMagic = 0x65735546 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be added to golang.org/x/sys/unix
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good one, yes
return nil | ||
} | ||
} | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does fusermount
return an error if target
is not mounted? If yes, we should filter it out somehow.
func unmount(target string, flags int) error { | ||
if isFUSE(target) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe move it to after a normal mount (need to be checked carefully how it would work).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise we're making unmount
do one extra syscall every time.
The mounter implementation seems not committed |
Ah, yes, I think I started looking at differences between containerd and this repo, and was not finished yet; thought I'd open to at least discuss if this would be in or out of scope for this repo |
I think as long as it's not introducing any noticeable overhead to "normal" mounts it's fine to have it. The question is what do we call "noticeable" :) |
Any chance of this moving forward? If I understand correctly this would allow mounting of FUSE filesystems like glusterfs using the docker's |
When m.Type starts with either fuse. or fuse3, the mount helper binary mount.fuse
or mount.fuse3 is executed.
Similar to the changes made in containerd: