about zfs and ashift and changing ashift on existing zpool

Peter Jeremy peter at rulingia.com
Mon Apr 8 21:28:41 UTC 2019

On 2019-Apr-07 16:36:40 +0100, tech-lists <tech-lists at zyxst.net> wrote:
>storage          ONLINE       0     0     0
>  raidz1-0       ONLINE       0     0     0
>    replacing-0  ONLINE       0     0 1.65K
>      ada2       ONLINE       0     0     0
>      ada1       ONLINE       0     0     0  block size: 512B configured, 4096B native
>    ada3         ONLINE       0     0     0
>    ada4         ONLINE       0     0     0
>What I'd like to know is:
>1. is the above situation harmful to data

In general no.  The only danger is that ZFS is updating the uberblock
replicas at the start and end of the volume assuming 512B sectors which
means you are at a higher risk or losing one of the replica sets if a
power failure occurs during an uberblock update.

>2. given that vfs.zfs.min_auto_ashift=12, why does it still say 512B
>   configured for ada1 which is the new disk, or..
The pool is configured with ashift=9.

>3. does "configured" pertain to the pool, the disk, or both
"configured" relates to the pool - all vdevs match the pool

>4. what would be involved in making them all 4096B
Rebuild the pool - backup/destroy/create/restore

>5. does a 512B disk wear out faster than 4096B (all other things being
>   equal)
It shouldn't.  It does mean that the disk is doing read/modify/write at
the physical sector level but that should be masked by the drive cache.

>Given that the machine and disks were new in 2016, I can't understand why zfs
>didn't default to 4096B on installation

I can't answer that easily.  The current version of ZFS looks at the native
disk blocksize to determine the pool ashift but I'm not sure how things
were in 2016.  Possibilities include:
* The pool was built explicitly with ashift=9
* The initial disks reported 512B native (I think this is most likely)
* That version of ZFS was using logical, rather than native blocksize.

My guess (given that only ada1 is reporting a blocksize mismatch) is that
your disks reported a 512B native blocksize.  In the absence of any override,
ZFS will then build an ashift=9 pool.

Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20190409/fc995fd3/attachment.sig>

More information about the freebsd-stable mailing list