I have attended some of the webinars and listen to Allan on a podcast regularly and this LLM-written post is painful to read. If I hadn't already been familiar with him and his work I would have not given much weight to what was written. He is a big proponent of tuning ZFS which requires knowing your workload for which he has written other guides.
1. From my own experience, most people who use a ZIL for faster sync writes are wasting space. You only need five seconds of peak throughput (for a 10Gb connection that's ~5 GB). Create a pair of 25 GB partitions for the ZIL rather than dedicating entire devices.
2. With the remaining space set up a mirrored Special VDEV with heavy use of small blocks. 32k block sizes will still give some room for compression which, other than saving space, can increase throughput and reduce IO/ps.
3. Pause scrubs (`zpool scrub -p`) when the workload is either expected to be heavy or is actually heavy based on moving averages and resume when its safe. Even my 24 TB NAS takes 24+ hours with no other activity.
> Even my 24 TB NAS takes 24+ hours with no other activity
Your NAS sounds pretty slow, it shouldn't take an hour to scrub 1tb of data (on average)
Yeah, the only place I use SLOG is with Optane devices in front of SATA/SAS flash. Anything that needs the speed of SLOG shouldn't be on rust anyways.
I would be in a different world if my system was backing banking or other loss critical data. For all my workloads, losing 5 seconds of writes in a crash is NBD.
> 1. From my own experience, most people who use a ZIL for faster sync writes are wasting space. You only need five seconds of peak throughput (for a 10Gb connection that's ~5 GB). Create a pair of 25 GB partitions for the ZIL rather than dedicating entire devices.
You might benefit from the same technique for a "special" vdev... If you run an all spinners array, but the metadata is on a small partition, you might get better seek times during metadata scans, since everything will be closer together? And/or if you use raidz for your regular vdev, but mirror for the metadata, you'll have more capacity for metadata reads.