Problem/Justification
There is currently only 512 and 4096 sector sizes available. You should add 8K, 16k, 32k, 64k to allow for more modern setups and reduce write amplication and imporve performance
I would add a note saying 512 is for legacy OSes like XP and 4096 is for modern OSes, where are the other ones are for specialist setups used within Enterprise etc…
Impact
These larger sector sizes are probably more for Enterprise but it does not harm having these sections
User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
The matching ZFS volume should be similar to the AShift size of the underlying media. Like 4K native disks. Using 8K volume block size and a 4K AShift works okay in the sense that 2 underlying blocks have to be read or written.
But, the opposite is problematic. Meaning a 4K AShift size for the underlying media but a 2K ZFS volume would cause read, modify and write cycles to the underlying media.
Next, their are changes headed to OpenZFS for AShift values. At present, 4K, (aka AShift 12), is okay but does eat into something called the Uber block ring buffer. This is because the Uber block ring buffer was fixed in size for 512 byte sectors and 128 Uber blocks, (if I remember correctly).
With huge disks available today, using 4KB sectors might be too small. So some work to allow 8K and 16K native sector sizes, (like for SSD / NVMe / U.2), and not eat up extra Uber block slots. In fact, the idea was to restore the Uber block ring buffer count back to 128, (or so?), even with huge sector sizes.
But, this will require pool format changes. Existing pools will be unable to take advantage of this improvement. So this will be one of the first pool backward compatibility break features since splitting from Oracle ZFS.
This is about the virtual disk size presented to a VM (TrueNAS as the host, running something else as a VM), NOT the physical sector size of the underlying data disks.
Even on a normal pool with ashift 4K on 4K media you still might want to use 16K volblocksize (to reduce metadata and improve compression). But (if the guest filesystem supports it) there isn’t really a reason to lie to it and pretend the VM has a virtual disk with 512b or 4096b sectors.
The zVOL processes I/O from the guest 16K aligned, so why not present the guest Kernel with a virtual disk that says physical sector size = 16K.
Windows can deal with that, and as of recently bs > ps support is also in Linux (IIRC. at least with ext4 and btrfs, probably also XFS)
However, just because you can do something, does not mean it will work well. What I was trying to say, is that ZFS was not designed to work at the top speed when using mis-matched storage sector size verses volume block size.
Yes, I understood that from the original post.
My comment was that adding mis-matched VM volume sizes could impact performance. Like @shoulders comment about using 512b volume block size, but using 4K native underlying sectors. That will cause performance issues, due to read, modify and write, on top of copy on write. Worse, if the pool is >50% used…
Anyway, for people doing casual VM & virtual block storage, ZFS should be fine. However, for those that expect serious performance, ZFS volumes are probably not the best answer.
