Date: Sat, 26 Feb 2022 12:29:12 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262189] ZFS volume not showing up in /dev/zvol when 1 CPU Message-ID: <bug-262189-227-GsxCqAe3lK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262189-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262189-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262189 --- Comment #6 from Janis <zedupsys@gmail.com> --- Thank's for the useful information, i did not know the internals in this regard. Now i understand what the bug #250297 report is speaking about. That bug seemed might be relevant to my case. I tried to reproduce it with zfs create/destroy shell script loop and could not hit kernel panic as stated t= here in comments. I did not get that he speaks about how volmode=3Ddev is created internally, so his use-case seemed a bit bizarre. About asynchronous nature for "zfs create" command. At first i thought this= is the case, but it does not seem to be. There are two problems as i see: 1) if this was just that "zfs create" returns too early, it would be a mini-bug, since it is expected that command returns when things are done. I guess, i wouldn't even report it. 2) with sleep between "zfs create" and "dd" on multi-core systems it "solve= s" some of dd problems, but not all of the missing ZVOL cases; there are still ZVOLs that never show up in /dev/zvol but can be seen in "zfs list". On sin= gle CPU case, it solves nothing at all and ZVOL never appears, only after reboot/export-import. To illustrate 1 CPU case, i run script: #!/bin/sh name_pool=3Dzroot/stress echo `date` ls /dev/zvol seq 1 10 | while read i; do zfs create -o volmode=3Ddev -V 1G $name_pool/data$i done sleep 300 echo `date` ls /dev/zvol Output is: Sat Feb 26 12:21:08 EET 2022 ls: /dev/zvol: No such file or directory Sat Feb 26 12:26:11 EET 2022 ls: /dev/zvol: No such file or directory even now after a while # date Sat Feb 26 12:35:03 EET 2022 # ls /dev/zvol ls: /dev/zvol: No such file or directory I do not know how long is considered asynchronous, but it seems too long, s= o i assume that ZVOL will never show up. With 1 CPU machine in file "cat /var/run/devd.pipe" i get lines like so for each create command: !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dzvol/zroot/stress/dat= a20 !system=3DGEOM subsystem=3DDEV type=3DCREATE cdev=3Dzvol/zroot/stress/data20 !system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/da= ta20 !system=3DGEOM subsystem=3DDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/data= 20 This seems wrong, since both "last" events are DESTROY. With 4 CPUs it is harder to reproduce, so i ran with 2 CPUs enabled in BIOS. Physical hardware, 16G RAM. So i ran script as follows: #!/bin/sh name_pool=3Dzroot/stress zfs create -o mountpoint=3Dnone $name_pool seq 1 1000 | while read i; do zfs create -o volmode=3Ddev -V 1G $name_pool/data$i done Testing result: # zfs list | grep stress | wc -l 1001 # ls /dev/zvol/zroot/stress/ | wc -l 638 Output clearly shows that ZVOLs are missing (even if ignoring output header= and ZVOL parent, diff is too big) I created files and will attach them (though maybe it is enough with my pointers): zfs list -H -o name > /service/log/zfs_list_001.log ls ls /dev/zvol/zroot/stress/ > ls_dev_zvol_stress__001.log cat /var/run/devd.pipe| grep -v "!system=3DZFS" > /service/log/grepped_devd.pipe_no_dd_seq_1000__001.log With diff and sorting we see that, i.e. there is no ZVOL for: -data526 -data527 -data528 -data529 # ls /dev/zvol/zroot/stress/data526 ls: /dev/zvol/zroot/stress/data526: No such file or directory # zfs get -H volmode zroot/stress/data526 zroot/stress/data526 volmode dev local For non-existing case we see this in devd.pipe file: # cat /service/log/grepped_devd.pipe_no_dd_seq_1000__001.log | grep data526 !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dzvol/zroot/stress/dat= a526 !system=3DGEOM subsystem=3DDEV type=3DCREATE cdev=3Dzvol/zroot/stress/data5= 26 !system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/da= ta526 !system=3DGEOM subsystem=3DDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/data= 526 It's the same fingerprint as in 1 CPU case, double destroy events are last ones. Whereas for existing ZVOLs there is: # cat /service/log/grepped_devd.pipe_no_dd_seq_1000__001.log | grep data525 !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dzvol/zroot/stress/dat= a525 !system=3DGEOM subsystem=3DDEV type=3DCREATE cdev=3Dzvol/zroot/stress/data5= 25 !system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/da= ta525 !system=3DGEOM subsystem=3DDEV type=3DDESTROY cdev=3Dzvol/zroot/stress/data= 525 !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dzvol/zroot/stress/dat= a525 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262189-227-GsxCqAe3lK>