zvols have a "volmode" property that controls how their device nodes are created: as geom devices (default), as non-geom character devices, or not at all. At least, it's supposed to do that. But on 13-CURRENT, the volmode property gets ignored at creation time. The device always gets created as the default type instead. The easiest way to demonstrate the problem is to use gpart on the device node. It isn't supposed to work if the node is a non-geom device. But it does! # zfs create -o volmode=dev -V 64m testpool/vol # gpart create -s gpt /dev/zvol/testpool/vol zvol/testpool/vol created However, if we change the volmode property after creation, then ZFS destroys and recreates the device node with the correct volmode. # zfs create -V 64m testpool/vol # zfs set volmode=dev testpool/vol # gpart create -s gpt /dev/zvol/testpool/vol gpart: arg0 'zvol/testpool/vol': Invalid argument
Has this been fixed? I can't seem to reproduce it: markj@nuc> sudo zfs create -o volblocksize=8192 -o volmode=dev -V 1G test/mark markj@nuc> sudo gpart create -s gpt /dev/zvol/test/mark gpart: arg0 'zvol/test/mark': Invalid argument There are intermittent CI failures that seem linked to the workaround for this PR in the AIO tests: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18936/ https://cgit.freebsd.org/src/tree/tests/sys/aio/aio_test.c#n918 Is there some race where the "zfs set" can cause the zvol device to go away briefly? FWIW I don't see any devd events to that effect if I create a dataset with volmode=dev and then zfs set volmode=dev again, which is what the test does.
I can reproduce it on: 14.0-CURRENT: no 13.0-RELEASE: no 12.2-STABLE: yes I think we can revert the workaround, as long as we don't MFC to stable/12.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=825fb07c55986971b1a20e40a73c12eb0ff432e0 commit 825fb07c55986971b1a20e40a73c12eb0ff432e0 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2021-08-13 22:59:10 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2021-08-14 00:01:18 +0000 aio: revert the workaround for bug 251828 in the tests This bug is no longer reproducible in 14.0-CURRENT and 13.0-RELEASE Do not MFC to stable/12 ! PR: 251828 Reported by: markj Reviewed by: markj MFC after: 2 weeks Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D31535 tests/sys/aio/aio_test.c | 7 ------- 1 file changed, 7 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4bfd530cca28c8e24de3f9a0d8b138f4644ffca9 commit 4bfd530cca28c8e24de3f9a0d8b138f4644ffca9 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2021-08-13 22:59:10 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2021-10-07 21:38:25 +0000 aio: revert the workaround for bug 251828 in the tests This bug is no longer reproducible in 14.0-CURRENT and 13.0-RELEASE PR: 251828 Reported by: markj Reviewed by: markj Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D31535 (cherry picked from commit 825fb07c55986971b1a20e40a73c12eb0ff432e0) tests/sys/aio/aio_test.c | 7 ------- 1 file changed, 7 deletions(-)
I tested this bug, whose fix seems to have introduced bug #262189 as reported by me. In 13.0-RELEASE there was no way to reproduce this bug. In each shown case received answer from gpart was: gpart: arg0 'zvol/testpool/vol': Invalid argument So i specially tested 12.2-RELEASE, but i could not repeat it exactly, but partially. I believe that it is due to the reasoning as in bug #262189, since i had virtual machine, VirtualBox, 1 vCPU assigned. Thus, in each case i got the same answer, volmode=dev was not respected at all. # zfs create -o volmode=dev -V 64m testpool/vol # gpart create -s gpt /dev/zvol/testpool/vol zvol/testpool/vol created # zfs create -V 64m testpool/vol # zfs set volmode=dev testpool/vol # gpart create -s gpt /dev/zvol/testpool/vol zvol/testpool/vol created But if i did this flow: # zfs create -V 64m testpool/vol # zfs set volmode=dev testpool/vol # .. reboot system .. # gpart create -s gpt /dev/zvol/testpool/vol gpart: arg0 'zvol/testpool/vol': Invalid argument then returned value is as expected. In 12.2-RELEASE i could not reproduce bug #262189