mount: support FUSE helper by AkihiroSuda · Pull Request #3765 · containerd/containerd

AkihiroSuda · 2019-10-19T16:32:54Z

When m.Type starts with either fuse. or fuse3, the mount helper binary mount.fuse or mount.fuse3 is executed.

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 snapshotter plugin. (EDIT: shiftfs functionality using fuse-overlayfs snapshotter is being covered in #3885)

theopenlab-ci · 2019-10-19T16:43:44Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 9m 34s (non-voting)

theopenlab-ci · 2019-10-19T16:54:43Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 9m 57s (non-voting)

theopenlab-ci · 2019-10-20T05:11:50Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 7m 28s (non-voting)

codecov-io · 2019-10-20T05:29:01Z

Codecov Report

Merging #3765 into master will decrease coverage by 0.07%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3765      +/-   ##
==========================================
- Coverage   42.42%   42.35%   -0.08%     
==========================================
  Files         130      130              
  Lines       14710    14735      +25     
==========================================
  Hits         6241     6241              
- Misses       7548     7573      +25     
  Partials      921      921

Flag	Coverage Δ
#linux	`45.71% <0%> (-0.1%)`	⬇️
#windows	`37.94% <ø> (ø)`	⬆️

Impacted Files	Coverage Δ
mount/mount_linux.go	`26.2% <0%> (-4.05%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 537afb1...e739314. Read the comment docs.

theopenlab-ci · 2019-10-20T05:40:30Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 13m 13s (non-voting)

Requires: * containerd/containerd#3765 * containers/fuse-overlayfs#133 --- Older commits were imported from containerd with the following commands: git filter-branch --prune-empty --subdirectory-filter snapshots/overlay --msg-filter 'cat; echo; echo This commit was imported from https://github.com/containerd/containerd/commit/${GIT_COMMIT}' master git tag --list | xargs git tag -d Signed-off-by: Akihiro Suda <[email protected]>

dmcgowan · 2019-10-22T21:50:33Z

I don't think this is generic enough. The options should probably just be the arguments.

Putting all args to Options is incompatible with mount(8) convention: http://man7.org/linux/man-pages/man8/mount.8.html#EXTERNAL_HELPERS

dmcgowan · 2019-10-22T22:00:10Z

We are trying to come up with a generic way to handle resources (specifically mounts and fuse processes) for 1.4. However, for these binaries it seems we could potentially make these pluggable on their own. A few questions I have since I am not as familiar with FUSE.

Will unmounting the target be sufficient for cleanup
Could this be done with a sequence of mount -t commands, what are these binaries additionally doing?
Does the mount need to be performed here inside of the containerd daemon or the shim?

AkihiroSuda · 2019-10-23T02:45:09Z

The interface is intended to be compatible with the external helper convention described in mount(8).

Will unmounting the target be sufficient for cleanup

Mostly yes, but some FUSE might want to register clean up shell command

Could this be done with a sequence of mount -t commands, what are these binaries additionally doing?

Yes, I can rewrite the PR to use mount -t command.

mount -t command actually invokes mount.fuse helper, as described in the mount(8) man page.

Does the mount need to be performed here inside of the containerd daemon or the shim?

Anywhere, in the daemon's mount namespace?

AkihiroSuda · 2019-10-23T02:55:25Z

Calling mount command may hit GNU vs busybox vs something incompatibility.
So it seems better to call mount.<type> helper directly.

dmcgowan · 2019-10-28T21:50:46Z

Thanks for the link, if mount.<type> has a defined format, then this make sense. It still doesn't seem necessary to handle fuse in a special way though. Maybe mount.<type>+<subtype> format or something like that, we could then do a binary lookup on mount.<type>.

Mostly yes, but some FUSE might want to register clean up shell command

How would this be registered? The plan for the new resource management proposal is that they would have the equivalent of mount and unmount. In this implementation though, there would have to be something else doing all this.

Anywhere, in the daemon's mount namespace?

I'm trying to think of this from a plugin perspective, if this was functionality we configured in the daemon, would that configuration need to be passed down to the shim.

AkihiroSuda · 2019-10-29T04:24:29Z

How would this be registered?

I was thinking that mount.proto should have repeated string umountPreCmd; repeated string umountPostCmd;

dmcgowan · 2019-10-29T22:44:39Z

I was thinking that mount.proto should have repeated string umountPreCmd; repeated string umountPostCmd;

I don't think that is a road we want to go down. If these mounts require additional behavior we should focus on defining that as a register-able plugin interface rather than adding hooks to existing types. How much of a requirement is that to get this PR useable for what you are doing? I would really like to be able to support this but want to know if I should focus more on getting that plugin stuff working.

AkihiroSuda · 2019-10-30T01:31:30Z

umountcmd stuff is just theoretical and not needed for most FUSE fs including fuse-overlayfs

AkihiroSuda · 2019-11-13T08:22:48Z

Updated PR. Now Unmount() calls fusermount -u for FUSE mounts as suggested by Giuseppe.

Thanks for the link, if mount. has a defined format, then this make sense. It still doesn't seem necessary to handle fuse in a special way though. Maybe mount.+ format or something like that, we could then do a binary lookup on mount..

Can it be follow-up PR when we face real usecase?

Anyway, fusermount logic is specific to FUSE.

theopenlab-ci · 2019-11-13T08:32:31Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 10m 51s (non-voting)

AkihiroSuda · 2019-11-15T04:49:54Z

cc @hinshun

hinshun · 2019-11-15T18:32:34Z

Thanks @AkihiroSuda. I think one issue I have with this method is that we prefer not to have duplicate FUSE drivers for a same snapshot, without doing special deduplication on the FUSE mount helper. If multiple containers share a layer, ideally there is a single FUSE driver along with the overlay mount for other layers (FUSE and non-FUSE).

@dmcgowan FYI, I described FUSE with context specific for containerd here: https://github.com/hinshun/hellofs#fuse-overview

As well as a changeset for hanwen/go-fuse that uses containerd.Mount (derived from the implementation of fusermount): https://github.com/hinshun/hellofs#hanwengo-fuse-changes

AkihiroSuda · 2019-11-15T19:21:37Z

@hinshun

This PR is for non-Go fuse binaries, especially fuse-overlayfs, which is needed for providing Copy-on-Write for rootless containers on non-Ubuntu/non-Debian kernels.
This is unrelated to the continuity & CRFS discussion, even though fuse-overlayfs supports CRFS.
Sorry if this was confusing.

For FUSE filesystems written in Go, an additional PR would be needed.

AkihiroSuda · 2019-11-21T00:34:29Z

@dmcgowan Can we move this forward?

AkihiroSuda · 2019-11-25T05:06:48Z

Note: #3841 is basically unrelated to this PR, though this PR might be useful for implementing #3841 as well

fuweid · 2019-12-11T15:13:31Z

Need more time to review this. Will update comment later.

AkihiroSuda · 2019-12-12T06:29:53Z

rebased

theopenlab-ci · 2019-12-12T06:33:41Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 4m 36s (non-voting)

giuseppe

the FUSE side LGTM

When m.Type starts with either `fuse.` or `fuse3`, the mount helper binary `mount.fuse` or `mount.fuse3` is executed. Signed-off-by: Akihiro Suda <[email protected]>

AkihiroSuda · 2019-12-31T19:17:40Z

updated PR to use FUSE_SUPER_MAGIC

theopenlab-ci · 2019-12-31T19:22:32Z

Build succeeded.

containerd-build-arm64 : SUCCESS in 4m 35s (non-voting)

fuweid

LGTM

we can move it forward.

dmcgowan

LGTM

The writeback=0 workaround should no longer be needed: containerd/containerd#3765 (comment) Signed-off-by: Akihiro Suda <[email protected]>

AkihiroSuda force-pushed the mount-fuse branch from 54a33ee to a6dd6aa Compare October 19, 2019 16:43

AkihiroSuda force-pushed the mount-fuse branch from a6dd6aa to 0469cac Compare October 20, 2019 05:03

AkihiroSuda force-pushed the mount-fuse branch from 0469cac to e9c211f Compare October 20, 2019 05:26

AkihiroSuda mentioned this pull request Oct 21, 2019

Support containerd v1.3 containerd/fuse-overlayfs-snapshotter#3

Closed

fuweid requested a review from crosbymichael October 22, 2019 15:15

dmcgowan reviewed Oct 22, 2019

View reviewed changes

giuseppe reviewed Nov 4, 2019

View reviewed changes

Comment thread mount/mount_linux.go Outdated

AkihiroSuda force-pushed the mount-fuse branch from e9c211f to 7ef3c7a Compare November 13, 2019 08:20

liaojh1998 mentioned this pull request Dec 12, 2019

[WIP] allow user namespace remapping using snapshotters #3885

Closed

AkihiroSuda force-pushed the mount-fuse branch from 7ef3c7a to cbf52e6 Compare December 12, 2019 06:28

giuseppe approved these changes Dec 13, 2019

View reviewed changes

liaojh1998 mentioned this pull request Dec 15, 2019

add user namespace remapping through Labels containerd/fuse-overlayfs-snapshotter#5

Merged

AkihiroSuda commented Dec 18, 2019

View reviewed changes

Comment thread mount/mount_linux.go Outdated

mount: support FUSE helper

e739314

When m.Type starts with either `fuse.` or `fuse3`, the mount helper binary `mount.fuse` or `mount.fuse3` is executed. Signed-off-by: Akihiro Suda <[email protected]>

AkihiroSuda force-pushed the mount-fuse branch from cbf52e6 to e739314 Compare December 31, 2019 19:17

fuweid reviewed Jan 3, 2020

View reviewed changes

dmcgowan approved these changes Jan 6, 2020

View reviewed changes

dmcgowan merged commit b9fad5e into containerd:master Jan 6, 2020

AkihiroSuda added a commit to containerd/fuse-overlayfs-snapshotter that referenced this pull request Aug 17, 2020

remove writeback=0 workaround

0c80e11

The writeback=0 workaround should no longer be needed: containerd/containerd#3765 (comment) Signed-off-by: Akihiro Suda <[email protected]>

AkihiroSuda mentioned this pull request Aug 17, 2020

remove writeback=0 workaround containerd/fuse-overlayfs-snapshotter#22

Merged

thaJeztah mentioned this pull request Sep 28, 2020

mount.isFUSE(): remove unused error return, and extract FUSE unmount to a function #4588

Merged

dcantah mentioned this pull request Jul 10, 2023

[Reverted in #8838] Add support for bind-mounts on Darwin (a.k.a. "make native snapshotter work") #8789

Merged

Conversation

AkihiroSuda commented Oct 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Uh oh!

theopenlab-ci Bot commented Oct 19, 2019

Uh oh!

theopenlab-ci Bot commented Oct 19, 2019

Uh oh!

theopenlab-ci Bot commented Oct 20, 2019

Uh oh!

codecov-io commented Oct 20, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

theopenlab-ci Bot commented Oct 20, 2019

Uh oh!

dmcgowan Oct 22, 2019

Choose a reason for hiding this comment

Uh oh!

AkihiroSuda Oct 23, 2019

Choose a reason for hiding this comment

Uh oh!

dmcgowan commented Oct 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AkihiroSuda commented Oct 23, 2019

Uh oh!

AkihiroSuda commented Oct 23, 2019

Uh oh!

dmcgowan commented Oct 28, 2019

Uh oh!

AkihiroSuda commented Oct 29, 2019

Uh oh!

dmcgowan commented Oct 29, 2019

Uh oh!

AkihiroSuda commented Oct 30, 2019

Uh oh!

Uh oh!

AkihiroSuda commented Nov 13, 2019

Uh oh!

theopenlab-ci Bot commented Nov 13, 2019

Uh oh!

AkihiroSuda commented Nov 15, 2019

Uh oh!

hinshun commented Nov 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AkihiroSuda commented Nov 15, 2019

Uh oh!

AkihiroSuda commented Nov 21, 2019

Uh oh!

AkihiroSuda commented Nov 25, 2019

Uh oh!

fuweid commented Dec 11, 2019

Uh oh!

AkihiroSuda commented Dec 12, 2019

Uh oh!

theopenlab-ci Bot commented Dec 12, 2019

Uh oh!

giuseppe left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AkihiroSuda commented Dec 31, 2019

Uh oh!

theopenlab-ci Bot commented Dec 31, 2019

Uh oh!

fuweid left a comment

Choose a reason for hiding this comment

Uh oh!

dmcgowan left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

AkihiroSuda commented Oct 19, 2019 •

edited

Loading

codecov-io commented Oct 20, 2019 •

edited

Loading

dmcgowan commented Oct 22, 2019 •

edited

Loading

hinshun commented Nov 15, 2019 •

edited

Loading