Comment by zenoprax
7 hours ago
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.
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.
That's an interesting idea. Reminds me of how people would put their swap partitions at the end for faster speeds. If I did an N-way mirror I get could attach/detach as needed and get much more performance on reads.
> 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)
I was off by 2x - last scrub took 12 hours.
I have 3x22 TB drives in a RaidZ1 pool with roughly 20TB of data and a scrub takes 18 hours. This sounds about right to me tbh.
I'm running five 8TB in a Z2 so I think that slows me down a bit more especially compared to people running mirrors. I'm going to kick a scrub off now and see if I'm misremembering.
---
No need, looks like it ran a few weeks ago:
scrub repaired 0B in 12:43:52 with 0 errors on Mon Jul 6 20:58:58 2026
VDEVs:
Data VDEVs - 4 x MIRROR, 2 wide, 12.73TB; Log VDEVs - 1 x DISK, 14.91TB, 1 wide; Cache VDEVs - 1 x 447.13 GiB
HW:
8 x WDC_WD140EFGX-68B0GN08; 2 x Micron_5300_MTFDDAK480TDS
Total space is 50.81TB of which 24.16TB is used. Frag on pool is reported at 21%.
Last Scrub took 11 hours 45 minutes 50 seconds.
1 reply →