Chunwei Chen
Chunwei Chen
@rgbriggs It's a local filesystem and it's not fuse. We know the the process stuck in audit is holding fd in the filesystem because it's shown in the vmcore dump.
@pcmoore I can try that, but there's really not much difference and nothing related to audit. And I have the vmcore so if you think there's something to look there...
``` crash> bt -l 188152 PID: 188152 TASK: ffff8f6e30ecdac0 CPU: 8 COMMAND: "rsync" #0 [ffffa6218ab6bc68] __schedule at ffffffff95a00af6 /usr/src/debug/kernel-5.10.168/linux-5.10.168-1.nutanix.20230215.el7.x86_64/kernel/sched/core.c: 3797 #1 [ffffa6218ab6bcf8] schedule at ffffffff95a00f3f /usr/src/debug/kernel-5.10.168/linux-5.10.168-1.nutanix.20230215.el7.x86_64/arch/x86/include/asm/bitops.h: 206 #2 [ffffa6218ab6bd18] schedule_timeout...
Yeah, I noticed just now. I work for different team than Eiichi and we use different build, but it does seem very similar.
Is the snapshot already mounted somewhere else?
When you saw the ELOOP error, can you manual mount the snapshot at the .zfs/snapshot/xxx location and would every thing work afterward?
Do this `mount -t zfs [email protected] /backup/xxxx/.zfs/snapshot/2016-04-10.000000Z/` It might not make sense to you, but I want to have an idea of which part in the code went wrong.
@odoucet Please try `strace mount.zfs [email protected] /backup/xxxx/.zfs/snapshot/2016-04-10.000000Z/`
The mount command returns success, I don't know why it wouldn't work for you.
What kind of test makes you think it's not supported? The notify stuff should be handled in the VFS layer, so you should be able to use it on ZFS.