Closed janlam7 closed 4 years ago
@janlam7 thank you for reporting this. Would it be possible for you to verify this small patch resolves the issue? Unfortunately, I don't have a test system handy which uses ZFS for the root filesystem.
diff --git a/module/os/linux/zfs/zfs_ctldir.c b/module/os/linux/zfs/zfs_ctldir.c
index 1e61ef0..3b2a6eb 100644
--- a/module/os/linux/zfs/zfs_ctldir.c
+++ b/module/os/linux/zfs/zfs_ctldir.c
@@ -1053,7 +1053,8 @@ zfsctl_snapshot_mount(struct path *path, int flags)
* on mount.zfs(8).
*/
snprintf(full_path, MAXPATHLEN, "%s/.zfs/snapshot/%s",
- zfsvfs->z_vfs->vfs_mntpoint, dname(dentry));
+ zfsvfs->z_vfs->vfs_mntpoint ? zfsvfs->z_vfs->vfs_mntpoint : "",
+ dname(dentry));
/*
* Multiple concurrent automounts of a snapshot are never allowed.
@behlendorf I ended up applying the patch below, and indeed it solves the issue, nice! I changed the paths to match the 0.8-release branch.
diff --git a/module/zfs/zfs_ctldir.c b/module/zfs/zfs_ctldir.c
index 8acbbb61c..db583a647 100644
--- a/module/zfs/zfs_ctldir.c
+++ b/module/zfs/zfs_ctldir.c
@@ -1053,7 +1053,8 @@ zfsctl_snapshot_mount(struct path *path, int flags)
* on mount.zfs(8).
*/
snprintf(full_path, MAXPATHLEN, "%s/.zfs/snapshot/%s",
- zfsvfs->z_vfs->vfs_mntpoint, dname(dentry));
+ zfsvfs->z_vfs->vfs_mntpoint ? zfsvfs->z_vfs->vfs_mntpoint : "",
+ dname(dentry));
/*
* Multiple concurrent automounts of a snapshot are never allowed.
The above patch does not seem to be enough for me. Even with it applied to zfs-0.8.2, snapshots under /.zfs/snapshot/
are still empty.
The debug message from /proc/spl/kstat/zfs/dbgmsg
is different from what is quoted above in that the path begins with /sysroot/
rather than (null)/
. The same debug message appears with and without the patch after accessing a snapshot under /.zfs/snapshot/
.
I am using linux kernel 5.2.20. I did not have this problem with zfs-0.8.1.
timestamp message
1571898386 spa.c:5623:spa_tryimport(): spa_tryimport: importing tank
1571898386 spa_misc.c:408:spa_load_note(): spa_load($import, config trusted): LOADING
1571898386 vdev.c:124:vdev_dbgmsg(): disk vdev '/dev/nvme0n1p3': best uberblock found for spa $import. txg 77982
1571898386 spa_misc.c:408:spa_load_note(): spa_load($import, config untrusted): using uberblock with txg=77982
1571898386 spa_misc.c:408:spa_load_note(): spa_load($import, config trusted): LOADED
1571898386 spa_misc.c:408:spa_load_note(): spa_load($import, config trusted): UNLOADING
1571898386 spa.c:5475:spa_import(): spa_import: importing tank
1571898386 spa_misc.c:408:spa_load_note(): spa_load(tank, config trusted): LOADING
1571898386 vdev.c:124:vdev_dbgmsg(): disk vdev '/dev/nvme0n1p3': best uberblock found for spa tank. txg 77982
1571898386 spa_misc.c:408:spa_load_note(): spa_load(tank, config untrusted): using uberblock with txg=77982
1571898386 mmp.c:249:mmp_thread_start(): MMP thread started pool 'tank' gethrtime 3559400002
1571898386 spa.c:7577:spa_async_request(): spa=tank async request task=1
1571898386 spa_misc.c:408:spa_load_note(): spa_load(tank, config trusted): LOADED
1571898386 spa_history.c:319:spa_history_log_sync(): txg 77984 open pool version 5000; software version unknown; uts (none) 5.2.20-1 #1 SMP PREEMPT Thu Oct 10 00:15:30 KST 2019 x86_64
1571898386 spa.c:7577:spa_async_request(): spa=tank async request task=32
1571898386 spa_history.c:319:spa_history_log_sync(): txg 77986 import pool version 5000; software version unknown; uts (none) 5.2.20-1 #1 SMP PREEMPT Thu Oct 10 00:15:30 KST 2019 x86_64
1571898386 spa_history.c:306:spa_history_log_sync(): command: zpool import -N tank
1571898424 zfs_ctldir.c:1086:zfsctl_snapshot_mount(): Unable to automount /sysroot/.zfs/snapshot/zfs-auto-snap_daily-2019-10-22-0530 error=512
I use initramfs created by dracut and openrc on the Funtoo distribution.
This issue got me as well. I too am using an initrd (though a homegrown one and not dracut).
I can mount a snapshot with the following
mount -t zfs pool/root@snap /mnt
but the snapshot files under /.zfs/snapshots are all empty.
Running Devuan Ascii. Patch worked fine against Debian's 0.8.2-3.
@Ryushin do you use initramfs?
@Ryushin do you use initramfs?
Yes, I use Sysvinit and initramfs. I also tested on a Debian Buster system with sysvinit and initramfs as well. So it worked on both Devuan and Debian.
Seems I spoke too soon. Looks like I found a different kind of bug related to this. I've applied the patch listed above. My rpool looks like this: rpool 1.27T 2.95T 176K none rpool/ROOT 145G 2.95T 50.1G / rpool/mysql 53.0G 2.95T 23.0G /var/lib/mysql rpool/mysql-log 5.79G 2.95T 1.44G /var/lib/mysql-log rpool/plexmediaserver 206G 2.95T 171G /var/lib/plexmediaserver rpool/spool 115G 2.95T 35.5G /var/spool rpool/virtual_machines 778G 2.95T 743G /var/lib/libvirt
I can see inside snapshots for rpool/ROOT: windwalker:~# ls /.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/ bin boot.tar.xz dead.letter etc lib lost+found mnt opt proc run share sys tmp var boot cdrom dev home lib64 media netshares path root sbin srv tftpboot usr
Looking inside snapshots for any other dataset in rpool results in "Too many levels of symbolic links" error: ls /var/lib/libvirt/.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/ ls: cannot access '/var/lib/libvirt/.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/': Too many levels of symbolic links
System information
Describe the problem you're observing
After upgrading from zfs-0.8.1 to zfs-0.8.2 the snapshots under the root filesystem do not automount anymore. I have my root on zfs. Snapshots below other filesystems automount normally. The snapshots can be mounted manually, so I have a workaround.
Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs
I bisected it to commit 093bb6446120c50a7109ed7e7a0f2e76730b3160 in which case the following warning is logged in dmesg