drivers: enhance check for mount fs type #1261
Conversation
drivers/driver_linux.go
Outdated
| if err := unix.Statfs(filepath.Dir(mountPath), &buf); err != nil { | ||
| return true, err | ||
| } | ||
| return FsMagic(buf.Type) != fsType, nil |
There was a problem hiding this comment.
Since this check was done above shouldn't this be return false, nil?
There was a problem hiding this comment.
buf is overwritten with the data from the parent directory, the check is on a different directory now
There was a problem hiding this comment.
Yup, now I see it it. I did not read the statfs line it was modifying buf as a side effect.
LGTM
If one FUSE filesystem is mounted somewhere below a different FUSE filesystem, why would we want this function to start to return
Can you elaborate on what this helps with? |
It helps because when using kata containers rootfs itself is running on FUSE: with such configuration we are not able to use fuse-overlayfs, even if it works fine on top of virtiofs. I've not found a way to inspect the kind of FUSE file system without parsing |
|
So we are trying to run "buildah bud" inside a kata container and that fails with error. Kata container rootfs is virtiofs which is backed by overlayfs on host. We were expecting that fuse-overlayfs will be used on top of virtiofs and that should work out of the box. But that's not happening for some reason. I don't understand this code fully but giuseppe pointed me to this code. So question is, what's wrong with running a fuse filesystem on top another and why filesystem type matters. And why we are not switching to using fuse-overlay. Kernel overlayfs will not work as it is because whiteout creation fails on top of host overlayfs. fuse-overlayfs can work as it will switch to regular file starting with .wh as whiteout. |
|
What's the error that this change helps us avoid? Is the overlay driver getting confused and "detecting" that a fuse-overlayfs mount is already mounted when it isn't, or is it something else? |
|
No idea. It will be good to have more explanation of current behavior and why that current behavior is not working on top of virtiofs. |
giuseppe
force-pushed
the
enhance-check-for-fs-type
branch
from
f10e276 to
4cbf3d4
Compare
the error is that the entire The proposed fix instead also checks that the target directory is a new mount point, different than its parent. |
|
I've rebuilt Thanks @giuseppe ! |
when checking that a mount has a specific file system type, also validate that it is on a different than its parent directory. This helps when using virtiofs as the underlying file system since the check used for fuse-overlayfs would fail since they both use FUSE. Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
force-pushed
the
enhance-check-for-fs-type
branch
from
4cbf3d4 to
da09b93
Compare
|
/approve |
|
LGTM |
when checking that a mount has a specific file system type, also
validate that it is different than its parent directory.
This helps when using virtiofs as the underlying file system since the
check used for fuse-overlayfs would fail since they both use FUSE.
Signed-off-by: Giuseppe Scrivano [email protected]