"iozone -w -i 1 -l 512 -r 4k -s 1g" against ZFS (without compression) can be a denial of service attack on a 32 GiByte RAM system

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389#c42
for an example of loss of control of a system via the extensive
OOM activity that resulted.

The problem has been observed on both amd64 and aarch64: the
original report was for amd64 and my activity was for aarch64.
The original reporter had both 16 GiByte RAM and 32 GiByte RAM
examples but first reported a 16 GiByte RAM context. My context
had 32 GiBytes of RAM (8 FreeBSD cpus).

The original report was against 14.0-RELEASE-p5. My activity is
15.0-CURRENT based.

For reference for my recent re-test, it is based on a PkgBase
kernel and world that reports:

# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT main-n273174-8b2e7da70855 GENERIC-NODEBUG arm64 aarch64 1500026 1500026

8b2e7da70855 is from 2024-Oct-23:

    • git: 8b2e7da70855 - main - llvm19: permit incremental builds from llvm18 Brooks Davis

For reference:

# ~/pkgbase-snapshot-list.sh
Via pkg-static info -C -x '^FreeBSD-' . . .
 352 FreeBSD-*-15.snap20241023235252
   1 FreeBSD-*-15.snap20241022122410
   1 FreeBSD-*-15.snap20241020224518
   1 FreeBSD-*-15.snap20241020094723
   7 FreeBSD-*-15.snap20241015203742
   1 FreeBSD-*-15.snap20241015145839
   1 FreeBSD-*-15.snap20241015120827
   1 FreeBSD-*-15.snap20241014101436
  34 FreeBSD-*-15.snap20241011184813
 129 FreeBSD-*-15.snap20241009162208
Instead via /var/cache/pkg/*.snap*.pkg . . .
 352 FreeBSD-*-15.snap20241023235252
   1 FreeBSD-*-15.snap20241022122410
   1 FreeBSD-*-15.snap20241020224518
   1 FreeBSD-*-15.snap20241020094723
   7 FreeBSD-*-15.snap20241015203742
   1 FreeBSD-*-15.snap20241015145839
   1 FreeBSD-*-15.snap20241015120827
   1 FreeBSD-*-15.snap20241014101436
  34 FreeBSD-*-15.snap20241011184813
 129 FreeBSD-*-15.snap20241009162208


Notes:

Prior initialization of the 512 iozone.DUMMY.* files
involved was via the likes of:

# iozone -i 0 -w -l 512 -+n -r 128k -s 1g

and letting that run to completion. That had been
done in a prior boot to avoid spending time
on rebuilding the 512 files in later testing.

My testing on an amd64 192 GiByte RAM system did not
reproduce the problem, despite being well below the
512 GiBytes for the files. (32 FreeBSD cpus.)
This context had Optane media via PCIe, not via USB3.
This AMD 7950X3D context is far faster generally.

===
Mark Millard
marklmi at yahoo.com