-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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 namespaces can make ZFS snapshots not automountable by normal processes #7849
Comments
I don't see this happening on 0.7.9:
|
Maybe something keeps the snapshot mounted in the cloned namespace? |
I was just able to reproduce my issue with 0.7.9 on Fedora 28 (with the latest, just-released kernel). I used a 15 second |
@siebenmann Debian8 with stock kernel:
|
Thank you for the script! I ran it on my test Fedora 28 machine and it reproduced the problem:
This is with 0.7.9 straight from the official ZoL Fedora repo, so all I can think of is some difference in either the kernel's behavior or the |
@siebenmann does this happen only with ZFS automounted snapshots? Please try the following script on that Fedora28 machine:
|
The held-in-namespace mount also happens with the /dev/loop0 mount:
Just to be sure, I tested a variant of your script that did a |
It is the
"util-linux" versions:
By default newer versions execute an additional
when unsharing the mount namespace : specifying
The issue here is we don't get to properly cleanup all the references ( The cleanup code path is Tracing relevant function calls via systemtap, without private mount:
and with private mount:
this is confirmed by the fact that we keep trying to umount the snapshot on the parent namespace (because after a "failed" umount we get "rescheduled" in
|
We have this problem with snapshot where we get |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
The disk device type now specifies the Can you confirm this fixes @siebenmann ? |
I will need to build a test environment and rebuild my familiarity with this bug, so it will be a few days before I can give you an answer here. |
The current state of git tip on Fedora 32 is confusing me but the issue is still present; the snapshot remains mounted in the second namespace even if it has been unmounted in the PID 1 namespace. Under some circumstances the snapshot seems to also remain mounted in the PID 1 namespace even though the timer has theoretically expired, but if I set a fast enough unmount time in @loli10K 's ZFS test script, I can see the snapshot mount disappear and then attempting to access it gets the same error. When the snapshot remains mounted in the PID 1 namespace, it appears to become slow to automatically unmount or perhaps doesn't really automatically unmount at all any more (I've waited several multiples of a 50 second unmount timeout and it is still mounted). (With the script's timing settings of a 50 second unmount timer and a 60 second sleep, the snapshot remains mounted in the PID 1 namespace. With a 15 second timeount it doesn't, although it stays mounted in the unshared namespace.) |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
System information
Describe the problem you're observing
Cloned mount namespaces can 'trap' ZFS snapshot automounts, making them mostly inaccessible to regular processes in the regular host namespace after ZFS expires the initial automount because ZFS will refuse to re-automount them. Under some circumstances this can lead to a panic in the NFS server code (see issue #7764), although it's not the only way to cause or reproduce that particular panic.
Describe how to reproduce the problem
ls /tank/tst/.zfs/snapshot/snap
.PS1="newns# " unshare -m sh
. This cloned mount namespace inherits the automounted snapshot.umount
in the regular mount namespace; if the snapshot is unused there, this will succeed. However, this doesn't unmount the snapshot in the cloned mount namespace.ls /tank/tst/.zfs/snapshot/snap
. However, this time around it will fail with the error of 'Too many symbolic links'.This happens because
zfsctl_snapshot_mount()
refuses to automount a snapshot if it is already mounted, but the actual check is implicitly merely 'is the snapshot mounted anywhere in any namespace' (implemented as 'is this still on our internal list of snapshots that are mounted' inzfsctl_snapshot_ismounted()
). The specific error isELOOP
for reasons explained in the comments further down inzfsctl_snapshot_mount()
.Unfortunately it's not clear to me what (if anything) can be done about this. It might be possible to make it so that ZFS snapshot automounts can only be present in the main (PID 1) mount namespace, but that feels like overkill because there are some situations where this works right in additional mount namespaces. I don't know if there's a way to make a re-mount work right if the snapshot is mounted but not in the main mount namespace, or if that would cause explosions.
(The good news is that systemd's handling of mount namespaces for regular units with things like
DynamicUser
orPrivateTmp
doesn't appear to have this problem; unmounts propagate into the modified mount namespace used by the service.)The text was updated successfully, but these errors were encountered: