[zfs-discuss] migrating a zpool to ashift=12?

Chris Siebenmann cks at cs.toronto.edu
Fri Oct 18 12:37:06 EDT 2013


| Let's not beat a dead horse. There are practical reasons not to use
| an ashift of 4K when the drive reports 512. I encourage you to read
| the thread "Specifying ashift when creating vdevs" in the illumos-zfs
| archive.
|
| Also, if the drive is 4K and it reports 4K, all is well (4K is
| used). If the drive is 512 and reports 512, all is well (512 is
| used). It's only when the drive is 4K but reports 512 that things go
| wrong (512 is used).  That _should_ become less of an issue as time
| moves forward and drives stop lying.

 The problem with creating ashift=9 pools today is that you cannot add a
properly reporting 4K drive to such a pool as a replacement for a dead
or outdated drive. Since increasingly you may not have any choice about
buying 4K drives, this makes an ashift=9 pool a problematic thing over
the long term. In turn I believe very strongly that allowing people to
innocently create ashift=9 pools without any warning today is not doing
them any favours; instead it is a HUGE BEARTRAP that is quite likely to
bite them in the long run.

 Fixing this ZFS issue superficially is relatively easy, but you will
get bad to terrible performance in the resulting pool. However, bad
performance beats a non-redundant pool and/or having to buy a lot of 4K
drives immediately and migrate all of your data to a new pool built on
them.

 Fixing the issue for real is likely to be quite difficult because it
requires real changes to ZFS block allocations to make them 4k-aligned
as much as possible even on ashift=9 pools. I suspect that no one has
any interest in that.

	- cks

To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscribe at zfsonlinux.org.



More information about the zfs-discuss mailing list