Both of them usually failed with: /usr/src/tests/sys/aio/aio_test.c:934: open failed: No such file or directory sys.aio.aio_test.vectored_unaligned: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19367/ https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19324/ https://ci.freebsd.org/job/FreeBSD-stable-13-amd64-test/782/ https://ci.freebsd.org/job/FreeBSD-stable-13-amd64-test/759/ sys.aio.aio_test.vectored_zvol_poll: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19361/ https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19325/ https://ci.freebsd.org/job/FreeBSD-main-aarch64-test/383/ https://ci.freebsd.org/job/FreeBSD-main-aarch64-test/374/ https://ci.freebsd.org/job/FreeBSD-stable-13-amd64-test/762/ https://ci.freebsd.org/job/FreeBSD-stable-13-amd64-test/759/
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0b159faaca08e6cc89abcd29b4b1360f97e18245 commit 0b159faaca08e6cc89abcd29b4b1360f97e18245 Author: Li-Wen Hsu <lwhsu@FreeBSD.org> AuthorDate: 2021-09-28 19:32:47 +0000 Commit: Li-Wen Hsu <lwhsu@FreeBSD.org> CommitDate: 2021-09-28 19:32:47 +0000 Temporarily skip flaky tset cases under sys.aio.aio_test in CI - sys.aio.aio_test.vectored_unaligned - sys.aio.aio_test.vectored_zvol_poll PR: 258766 Sponsored by: The FreeBSD Foundation tests/sys/aio/aio_test.c | 5 +++++ 1 file changed, 5 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=095d3f98fb3d907fbd2e5c799bb2988532e9bf63 commit 095d3f98fb3d907fbd2e5c799bb2988532e9bf63 Author: Li-Wen Hsu <lwhsu@FreeBSD.org> AuthorDate: 2021-09-28 19:32:47 +0000 Commit: Li-Wen Hsu <lwhsu@FreeBSD.org> CommitDate: 2021-09-29 19:38:35 +0000 Temporarily skip flaky tset cases under sys.aio.aio_test in CI - sys.aio.aio_test.vectored_unaligned - sys.aio.aio_test.vectored_zvol_poll PR: 258766 Sponsored by: The FreeBSD Foundation (cherry picked from commit 0b159faaca08e6cc89abcd29b4b1360f97e18245) tests/sys/aio/aio_test.c | 5 +++++ 1 file changed, 5 insertions(+)
It looks like the problem may be related to the fact that openzfs creates the zvol character device asynchronously. So it's possible that the device file doesn't exist immediately after the zpool command returns.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=36d971464ac21f6531cb9eaa377f4e1dd915a2ad commit 36d971464ac21f6531cb9eaa377f4e1dd915a2ad Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2026-04-09 01:08:45 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2026-04-09 01:10:13 +0000 geom: Make g_waitidle() wait for orphaned providers This is motivated by the following race in the ZFS zvol code. When a zvol is created, we create a GEOM-backed zvol, which results in a /dev/zvol/<zvol path> device file, created by GEOM::dev. If volmode=dev is specified, zvol_set_volmode_impl() will wither the GEOM, then create a device file with the same name. This sometimes fails because g_wither_geom() is asynchronous, so we end up trying to create a device file while the old one still exists. I want to fix this by adding a g_waitidle() call to zvol_os_remove_minor(). g_waitidle() is not sufficient: GEOM::dev does not destroy the device until g_dev_orphan() is called. (In fact the device destruction is asynchronous too, but the delist_dev() call is sufficient to address this race.) So, I propose modifying g_waitidle() to block until orphaned providers are processed. PR: 258766 Reviewed by: mav, imp, kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D55049 sys/geom/geom_event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)