Weird ashift values on "zpool get ashift"

OpenZFS
1

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?

2

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.

3

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
4

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!

5

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
6

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       -