Working with refurbished hardware, I noticed that IncusOS hardcodes the 2026-sensible default of asize=12 on pool creation. However, I’m working with a stack of older SAS drives (yeah 
) that have native 512B sector sizes. Would it be of wider utility to have an option to specify (or override) asize=9, or should I go the hackish route where I create a pool with the right value and then import it using import-storage-pool? I wouldn’t be asking if there were an end in sight of current price levels.
Yeah, feels like something we can add to the create-pool logic easily enough.
We’d probably phrase it as alignment or something similar, then set the correct ashift behind the scenes.
Feel free to file a request at Sign in to GitHub · GitHub
The main downside of an ashift=9 zpool is that down the road if you add a 4KiB native drive you’ll get massive write amplification as ZFS’s use of 512 byte blocks will force the new drive to rewrite its 4KiB sectors multiple times.
Conversely, ashift=12 on a 512 byte native drive does waste a little bit of space when not performing writes that are multiples of 4KiB, but that overhead amortizes towards zero pretty quickly for large writes. Probably the only workloads to benefit from an exact alignment match with the smaller sector size would be lots of small writes, or possibly some raidz configurations based on comments I’ve seen online.
Supporting different alignments wouldn’t be hard to do, but also feels like it could be an easy gotcha that we’ll want to properly warn about.
I concur: ashift=12 is The Right Thing™ even with 512 byte sector drives. You lose a few percent in overall storage capacity, but the downsides of ashift=9 are pretty major (I’ve been bitten in the past, but it was so long ago I’d have to dig for the details).
thank you for the replies everyone, much appreciated.
Yeah, the use-case is a couple of raidz2 sets. I have a stack of spares, so replacement with 4K drives is quite unlikely. I’ll do some more research in benchmarks. If the difference is negligible, all the better.
The counterarguments make a lot more sense to me in the general case, so I understand if this will remain unsupported.