The mention of this in the other thread was in the context of using SSDs.
SSDs have 4k sector size, but because they originally were designed to be a “drop-in” replacement for HDD most emulate 512 sector size. It’s called 512e, e stands for emulated
But because magic does not exist – when you write 512-size sector, on the background SSD has to read 4k sector, modify 512 block, and write 4k sector. This has two undesirable consequences:
- Flash wear 4k/512=8x faster.
- Because of this read-modify-write and wear leveling algorithms SSDs employ failure during write of new data can corrupt unrelated data you wrote months before. This is horrific property is intrinsic to SSD design, but write amplification exacerbates the problem. (SMR drives exhibit the same behaviour)
Most OSes will default to 512 sector size if the deivece supports it, and since these SSDs “do” – that’s what will end up being used.
For those using zfs – the parameter you want to override is “ashift”, you need to set it to number if bits, in this case 12 (2^12=4k). You can list ashift values on the existing array like so:
zdb -U /data/zfs/zpool.cache | grep ashift
ashift: 12
ashift: 12
ashift: 12
ashift: 12
There is the whole other realm of what sector size to pick from the perspective of the filesystem – 512 vs 4k, but beyond some exotic scenarios, the answer is usually a multiple of “whatever is native to the drive”, especially with zfs that supports compression and does not waste the whole “sector” for a file (not to be confused with the native sector size on the device).