I created the pool with ashift=12, but when I do zpool get ashift zroot all-vdevs, I get a strange result
NAME PROPERTY VALUE SOURCE
root-0 ashift 0 -
cannot get vdev property name from luks-INTEL_XXX in zroot: invalid argument for this pool operation
cannot get vdev property ashift from luks-INTEL_XXX in zroot: invalid argument for this pool operation
raidz2-0 ashift 12 -
luks-WDC_WD60EFPX-XXX ashift 9 -
luks-WDC_WD60EFPX-XXX ashift 9 -
luks-WDC_WD60EFPX-XXX ashift 9 -
luks-WDC_WD60EFPX-XXX ashift 9 -
luks-INTEL_XXX ashift 12 -
This is actually a new pool I’ve created and then zfs recv from the old one because I thought I had messed up somewhere. I did make sure to pass ashift=12 both when creating and when zfs replace (since I only have 4 drives, I had to create the raidz2 with 2 temporary dummy drives)
I believe properties for vdevs is a relatively new feature, and it might just be that it’s a display bug, as it doesn’t make sense to me that drives/vdev that are part of a vdev can have a different ashift than the vdev itself.
Or is this something I should be concerned about, and if yes, how do I fix it?
I think that is both a display bug, and that what you’re seeing is probably either the LOG vdev or the CACHE. But with the actual device names partially elided, it’s impossible to be certain.
the “cannot get vdev” error I’m not worried about (in that case it’s the cache vdev), the 4 WDC drives (LUKS to be more exact) are the members of the raidz, and those are the ones shown as ashift=9, which is weird to me.
Ah, gotcha. Agreed, it’s pretty weird seeing a different ashift value on vdev members than on the vdev itself. For that matter, it’s weird seeing an ashift value on a vdev member at all.
I’d recommend filing a bug report at the OpenZFS GitHub and seeing what comes of it. And please update us with what you find out!
I had a similar finding on one of my pools today. I created an issue for it on github:
These ashift values on device level are not relevant for zfs operations. The ashift=12 on pool level is relevant. What zfs shows here with ashift=9 is what the device theoretically would get when you do not overwrite the ashift value during pool creation.
Check the devices with fdisk -l /dev/device. It will eventually show you a sector size of just 512 bytes. While your luks-INTEL_XXX is reportin ashift=12 because it has 4096 bytes sector size.