"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
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 03 Nov 2024 03:48:26 UTC
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