Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" possible file odd result
Date: Tue, 05 Sep 2023 18:13:43 UTC
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