ZFS Zpool avec ashift erroné. Est-ce grave?
J'ai un RAIDZ1 ZFS (ZoL) 3x1To. Un lecteur a échoué. Je le remplace par un disque de 4 To.
$ Sudo zpool replace pool <old guid> /dev/disk/by-id/<new id>
cannot replace <old guid> with /dev/disk/by-id/<new id>:
new device has a different optimal sector size;
use the option '-o ashift=N' to override the optimal size
$ zdb -C | grep ashift
ashift: 9
$ Sudo zpool replace pool <old guid> /dev/disk/by-id/<new id> -o ashift=9
Cela marche. Le tableau est maintenant en train de résumer. Cependant, pour être honnête, je n'ai pas compris l'impact de ce paramètre. Je voulais simplement remplacer le disque défectueux dès que possible et remplacer les autres disques de 1 To par des disques de 4 To dans un avenir proche. Mais avec le recul, performance avec un décalage d'alignement de 2 ^ 9 est décrit comme horrible .
Je comprends que ce paramètre est immuable. Une fois les deux autres disques remplacés, je ne peux pas modifier la valeur ashift en 2 ^ 12, qui est, si je comprends bien, recommandée pour les disques de 4 To.
Est-ce que je viens de me tirer une balle dans le pied? Quelle est la meilleure façon de procéder? Puis-je désactiver autoexpand et créer un nouveau volume sur le nouveau réseau avec ashift=12 et copier l'ancien volume sur le nouveau volume du même lecteur? Est-ce possible et recommandable?
Si vous choisissez une valeur ashift trop petite, le disque effectuera une lecture-modification-écriture en interne lorsque vous écrivez. Que vous remarquiez ou non que les performances dépendent des caractéristiques de votre utilisation - effectuez-vous beaucoup d’écritures synchrones et avez-vous besoin de très hautes performances? Si la réponse est oui, vous remarquerez la différence, mais sinon, vous pourriez ne pas le faire. Cela n’affecte pas autant les écritures asynchrones, car elles sont regroupées dans de grandes mises à jour multi-blocs, ce qui signifie qu’il n’y aura pas beaucoup d’écritures de sous-blocs (car seuls le premier et le dernier blocs d’une grande écriture contiguë peuvent être sous-traités). -bloquer).
L’inconvénient principal du passage aux blocs de 4 Ko est que la compression ne fonctionnera pas aussi bien, car elle ne peut arrondir les blocs compressés qu’au 4 Ko le plus proche au lieu des 512 Ko les plus proches. Si cela vous importe plus que les performances d’écriture haut de gamme, laissez-le tel quel.
Si les performances en écriture importent vraiment, vous devez reconstruire le pool. Je pense que le moyen le plus simple serait de faire un zfs send/zfs receive dans un nouveau pool configuré comme vous le souhaitez.
En ce qui concerne votre suggestion spécifique d'éviter d'acheter tout le matériel du nouveau pool en même temps et d'effectuer un nettoyage propre send/receive: puisque vous avez déjà des données écrites avec ashift 9, vous pouvez N'ajoutez pas un disque avec ashift 12 au pool (ZFS ne serait pas en mesure d'adresser les blocs alignés 512B sur le disque aligné sur 4 Ko; ashift est un paramètre défini sur vdevs de niveau supérieur. , pas des disques) - d’où l’avertissement que vous avez vu. Il serait peut-être possible de créer un nouveau pool sur la seconde moitié du nouveau lecteur et de copier toutes les données du premier pool sur celui-ci, mais la redondance de ce dernier ne serait pas la même que celle du pool d'origine, car vous ne pouvez pas construire un RAIDZ1 sur une partition d'un disque. Peut-être pourriez-vous copier dans le second pool sans redondance, puis reconfigurer les disques/partitions du pool d'origine dans la redondance ashift/correcte, puis copier toutes les données.