Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" possible file odd result

Just FYI:

For the specific machine/storage media combination
used for the openzfs import testing, the following
combination seemed to work well relative to the
subject of the "odd result":

A) /etc/sysctl.conf having "vfs.zfs.per_txg_dirty_frees_percent=30"

B) autotrim off but use of "zpool trim -w zamd64" first, after any
   freeing of space by deleting files. (Probably again after the
   build and any cleanout of the tempprary results.)

C) Avoid having more poudriere builders than hardware threads.

Of course, the combination does not apply to media that does not
have trim accessible (USB3, for example) --and that may not
support trim in some cases (Optane, for example).

By contrast . . .

In a USB3 context, vfs.zfs.per_txg_dirty_frees_percent=30 did
not work well because of the delete sequence when a builder
is to be reused for its next build.
vfs.zfs.per_txg_dirty_frees_percent=5 allowed more overall
progress on that aarch64 system. The big cleanout of all the
builders at the end is not the only consideration in setting
vfs.zfs.per_txg_dirty_frees_percent (for at least some systems).

===
Mark Millard
marklmi at yahoo.com