4 ms·
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
by zenoprax 3mo 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.
- secabeen 3mo agoYeah, 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.
- toast0 3mo ago> 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.
- zenoprax 3mo agoThat'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.
- nubinetwork 3mo ago> 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)
- ls612 3mo agoI 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.
- myrandomcomment 3mo agoVDEVs: 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.
- ls612 3mo agoMine are WD Red Pros. I also have a 2TB WD Black SSD as a cache VDEV for the pool.
- zenoprax 3mo agoI'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
- zenoprax 3mo agoI was off by 2x - last scrub took 12 hours.