Weird ashift values on "zpool get ashift"

I have the following pool:

        NAME                                                 STATE     READ WRITE CKSUM
        zroot                                                ONLINE       0     0     0
          raidz2-0                                           ONLINE       0     0     0
            luks-WDC_WD60EFPX-XXX                            ONLINE       0     0     0
            luks-WDC_WD60EFPX-XXX                            ONLINE       0     0     0
            luks-WDC_WD60EFPX-XXX                            ONLINE       0     0     0
            luks-WDC_WD60EFPX-XXX                            ONLINE       0     0     0
        logs
          luks-INTEL_SSDPEK1A118GA_XXX                       ONLINE       0     0     0
        cache
          luks-INTEL_SSDPEK1A118GA_XXX                       ONLINE       0     0     0

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.

Thanks for the reply. To clarify:

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.

1 Like

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.

1 Like

I see something similar on my pool (ZFS 2.2.6)

NAME      PROPERTY  VALUE   SOURCE
root-0    ashift    0       -
mirror-0  ashift    12      -
ata-WDC_WD50NDZW-11MR8S1_WD-WX11E690XXXX  ashift    9       -
ata-WDC_WD50NDZW-11C8XS0_WD-WX12D44EXXXX  ashift    9       -
mirror-1  ashift    12      -
ata-WDC_WD50NDZW-11MR8S1_WD-WX11E69HXXXX  ashift    9       -
ata-WDC_WD50NDZW-11BCSS1_WD-WX92D548XXXX  ashift    9       -