Hugin Laptop /etc/modprobe.d/zfs.conf

# To print a list of zfs parameters, use this command:
#   modinfo zfs
#
# Tweaker links:
# https://wiki.freebsd.org/ZFSTuningGuide
# https://icesquare.com/wordpress/how-to-improve-zfs-performance/
# https://www.freebsd.org/doc/handbook/zfs-advanced.html

# This is tuned for my Toughbook with 16GB RAM.
# 512MB min, 2048MB max (approximately)
# RAM is super scarce right now and browsers tend to chew through it like
# nobody's business (it's 2021 now, and it keeps getting worse).
# If the ARC is mostly being used for cached disk I/O, then I think it might
# have a poor cost-to-benefit ratio in my workflow, which is mostly web
# browsing, text editing, and playing media. I'm not on a webserver where
# randos from the internet are all going to be asking for the SAME resource
# over and over. Rather, I'll be doing something novel all the time, because
# my gray matter already provides some soft-cache. The ARC is thus slightly
# redundant. It'd still be helpful perhaps, but it comes at an enormous cost:
# causing my browsers to page A TON and possibly forcing a bunch of in-kernel
# disk-I/O and other mysterious hard-to-profile operations. So I'm going to
# try limiting the ARC and see if we can take memory pressure off of other
# parts of the system. I also prefer to have a little latency when I read
# coldbits off the disk, than to have ARC and Chrome/Firefox constantly
# battling for RAM while constantly churning coldbits without my knowledge
# or request. I'm not sure if that's happening, but it'd make sense, and it
# would be very non-consensual and rude. Hopefully, by asserting myself here,
# we can get some sanity back. Maybe. We'll see.
options zfs zfs_arc_min=512004096
options zfs zfs_arc_max=2048004096

# Flush transaction groups every 2 second.
# The default is probably higher, like 5 or 30. (Hard to tell which; there
# seem to be differences between OSes, or even just what articles report.)
# In principle, lowering this will cause it to write to disk in smaller,
# more frequent, bursts. Raising it causes bursts of intense disk I/O, but
# it happens less frequently. For servers, bursting might benefit from
# economics of scale and thus be slightly more efficient.
# For a desktop environment where responsiveness is more important than
# throughput, I suspect that lowering this could thus help with occasional
# stalling: we are effectively forcing it to interleave its disk activity
# with everything else we are doing by placing a soft-cap on the amount
# of spurious disk activity it can save up and dump on us all at once.
options zfs zfs_txg_timeout=1

# I'm going to try turning off prefetching.
# I'm not confident that this will help. It could always suck.
# Prefetching tries to anticipate what disk sectors a program is going to
# read before it reads them. This is neat if it can do so *well*. I'm skeptical.
# For random I/O, which is more like what I do, it will probably have, like the
# ARC, a poor cost-to-benefit ratio.
# The cost is that if I'm doing a lot of random reads, then it might try to
# grab a bunch of extra stuff EVERY TIME, thus multiplying the number of
# reads performed. The hypothesis then looks like this: the system envisions
# needing to do a bunch of reads (it doesn't), then the system becomes I/O
# bound (and it doesn't necessarily appear in iotop because it could be
# compression/encryption time in CPU or kernel threads), then the system
# tries to prefetch based on new read requests in order to reduce I/O
# pressure, thus issuing more read requests, and it all goes pear-shaped.
# Thus, if we take this to its logical extreme, then it could explain some
# of the nasty stalling and live-locking type of activity that's going on
# in the system.
options zfs zfs_prefetch_disable=1