@prez02 Thank you for pointing that out! I’ll use the article to make sure it’s working as expected.
@etorix using ashift=9 on 512B drives has several advantages:
-
Matching sector size means each ZFS block writes directly to a single physical sector without padding. If i would use ashift=12, if my data doesn’t fit naturally into 4k multiples ( for example small files, which i have lots of, or even metadata), I waste space because ZFS has to pad data to 4k.
-
Write amplification avoidance: with ashift=12 on a 512B drive, small writes (less than 4K) cause unnecessary writes:
- Example: A 1KB write on ashift=9 touches two 512B sectors.
- But on ashift=12, the same 1KB write forces ZFS to modify a full 4K block. (This results in read-modify-write overhead.)
- The drive physically has to read 4K, modify part of it, and write 4K back instead of just writing 1K efficiently.
This means writes are amplified, more latency, unnecessary drive wear
I totally get being cautions and using ashift=12 for most use-cases, because if one of your 512B drive fails and you have to replace it, you need another 512B drive. But my case is not usual, remember, I have 10 spare HDDs! And I’m fine with tinkering, I don’t mind having to copy the whole pool to a future new pool using 2 computers/servers. I get that most of the time, going with the norm, or the defaults, or what everybody usually recommends is ok. However, sometimes it’s ok to use something else, if you have an edge case, and the “norm” doesn’t fit your needs.