Greg Troxel wrote: > > That's a good test, but how does zfs compare in for the same test with lets > > say ffs or ext2fs (filesystems that offer persistence)? > > With the same system, booted in the same way, but with 3 different > filesystems mounted on /tmp, I get similar numbers of failures: > > tmpfs 12 > ffs2 13 > zfs 18 > > So tmpfs/ffs2 are ~equal and zfs has a few more failures (but it all > looks a bit random and non-repeatable). So it's hard to sort out "zfs > is buggy" vs "some tests fail in timing-related hard-to-understand ways > and that seems provoked slightly more with /tmp on zfs".
Since I'm all too familiar with the randomly failing tests in the NetBSD test suite, let me sort them out for you. Of the test cases in the zfs run that didn't match the releng results, these two are known random failures reported in PR 55770: > ./usr.bin/cc/t_tsan_data_race:data_race_pie > ./usr.bin/c++/t_tsan_data_race:data_race_pie This is probably the known random failure reported in PR 55692: > ./fs/nfs/t_rquotad:get_nfs_be_1_group This failure is already reported in PR 55603, though your report is the first of it failing on real hardware: > ./modules/t_x86_pte:svs_g_bit_set This one is reported as randomly failing in PR 55331, but since that problem appears to be tmpfs related, it may be the case that tmpfs and zfs are both buggy: > ./lib/libarchive/t_libarchive:libarchive The remaining four failed test cases are _not_ known to fail randomly, and as far as I know, do not have existing PRs. Since they all involve file system operations, it seems likely that they are in fact zfs related in some way: > ./bin/cp/t_cp:file_to_file > ./lib/libc/stdlib/t_mktemp:mktemp_large_template > ./lib/libc/sys/t_stat:stat_chflags > ./usr.bin/ztest/t_ztest:assert -- Andreas Gustafsson, g...@gson.org
