Un miroir ZFS peut-il utiliser des disques avec des tailles de secteur différentes ?

C’est possible, mais le vdev utilise une seule politique ashift et l’exigence de secteur physique la plus élevée devrait prévaloir afin d’éviter les pénalités de lecture-modification-écriture.

La décision est importante lorsqu’un disque de remplacement signale des secteurs physiques de 4K alors que le membre miroir survivant a été créé avec un alignement plus petit. Les deux états concurrents sont une géométrie de vdev compatible et un ashift fixe sous-optimal ou une capacité insuffisante. Commencez avec une configuration enregistrée et des données jetables, observez une seule branche à la fois et arrêtez-vous si le test accroît les risques de perte de données, de permissions ou de disponibilité.

Définir les conditions derrière la décision concernant un miroir ZFS à secteurs mixtes

Consignez l’environnement avant toute modification : versions des logiciels et des micrologiciels, identités des périphériques, chemin de montage ou réseau, espace libre, permissions et symptôme observable. La référence de départ doit conserver suffisamment de détails pour reproduire le cas où un disque de remplacement signale des secteurs physiques de 4K alors que le membre miroir survivant a été créé avec un alignement plus petit.

Le premier candidat est une géométrie de vdev compatible. Le second est un ashift fixe sous-optimal ou une capacité insuffisante. La propriété ashift d’OpenZFS actuelle définit le mécanisme ou la limite de commande utilisés lors du test ; elle ne remplace pas l’observation effectuée sur ce serveur domestique précis.

Rédigez la condition d’acceptation et la condition d’arrêt avant d’exécuter le test discriminant. Une réussite doit modifier les éléments probants prédits par une branche tout en laissant les services sans rapport inchangés ; un échec doit ramener le système à l’état enregistré plutôt que déclencher une série de corrections spéculatives.

Tester l’hypothèse sans réduire l’exigence initiale

Utilisez ce test discriminant : inspectez l’ashift existant et les rapports de secteurs logiques/physiques des disques, puis mesurez les écritures alignées sur un pool réplique. Conservez la charge de travail, le client, le chemin, l’ensemble de fichiers et le calendrier constants afin que le résultat soit attribuable à la variable modifiée.

Utilisez le comportement de zpool sous FreeBSD pour sélectionner le champ capable de séparer réellement les branches, puis capturez son horodatage, son statut de sortie, le texte de l’erreur, l’identité du périphérique ou de l’instantané, la latence, les octets transférés, les permissions et l’état de récupération. Une sortie de commande réussie ne suffit pas lorsque l’identité, la durabilité ou l’état de l’application constituent l’hypothèse testée.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou un cache froid lorsque cet événement fait partie de la condition initiale. Si la première exécution est destructive ou si l’environnement ne peut pas être restauré, arrêtez-vous et reproduisez le test sur une copie jetable.

zpool get ashift pool
lsblk -o NAME,LOG-SEC,PHY-SEC,SIZE

Interpréter les résultats de réussite, d’échec et d’exception

RÉUSSITE : le remplacement est attaché, la reconstruction est terminée et la latence des écritures alignées reste acceptable. Consignez la version exacte, l’identité et la charge de travail ayant réussi afin que la conclusion reste conditionnelle au lieu de devenir une affirmation universelle.

ÉCHEC : l’ashift est trop petit, le remplacement est légèrement plus petit ou les performances se dégradent avec les écritures synchrones et aléatoires. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les permissions ou la cohérence de la source peuvent influencer les deux branches ; isolez ces dépendances communes avant toute escalade.

EXCEPTION OU RÉSULTAT AMBIGU : utilisez un remplacement adapté ou reconstruisez un nouveau pool correctement aligné plutôt que de forcer l’utilisation d’un disque trop petit. Conservez les journaux et n’exécutez aucune commande de réparation, de purge, de destruction, de repartitionnement ou de modification récursive de la propriété avant de disposer d’une copie récupérable.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirmer la décision avec la charge de travail initiale

Appliquez l’action correspondant à la branche observée, puis reproduisez la condition initiale plutôt qu’un substitut simplifié. La décision n’est confirmée que lorsque le remplacement est attaché, la reconstruction est terminée et la latence des écritures alignées reste acceptable sur deux cycles ou lors du redémarrage, de la mise en veille, de l’interruption ou du changement de charge pertinent.

Utilisez les tailles de secteurs des miroirs ZFS pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur initial inchangé. Les jeux de données, partages, conteneurs, utilisateurs et points de récupération sans rapport doivent conserver leur accès et leur calendrier précédents.

La limite d’arrêt est explicite : si l’ashift est trop petit, si le remplacement est légèrement plus petit ou si les performances se dégradent avec les écritures synchrones et aléatoires, revenez à la dernière configuration vérifiée, conservez les éléments probants et ne procédez à un test approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible obtenu, comparez-le à la vérification de restauration afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi accompagné d’une nouvelle défaillance de sauvegarde, d’identité, de délai d’expiration ou de disponibilité reste une modification échouée.

FAQ

Pour les miroirs ZFS à secteurs mixtes, les recherches restantes portent généralement sur la possibilité de modifier l’ashift après la création du vdev, l’utilisation de ashift=12 pour les disques 4K et l’importance d’une capacité différente. Les réponses ci-dessous séparent ces cas particuliers de la décision principale.

La limite d’acceptation ne change pas : le remplacement est attaché, la reconstruction est terminée et la latence des écritures alignées reste acceptable. Si une condition de suivi modifie le système de fichiers, l’identité, le chemin réseau ou la version de l’application, répétez uniquement le test discriminant affecté par cette modification.

Arrêtez d’élargir l’expérience lorsque l’ashift est trop petit, que le remplacement est légèrement plus petit ou que les performances se dégradent avec les écritures synchrones et aléatoires. À ce stade, utilisez un remplacement adapté ou reconstruisez un nouveau pool correctement aligné plutôt que de forcer l’utilisation d’un disque trop petit ; conservez les éléments probants avant toute escalade vers le responsable de la plateforme, du stockage ou du matériel.

Peut-on modifier l’ashift après la création du vdev ?

Pas directement pour un vdev existant ; la correction habituelle consiste à reconstruire ou à créer un nouveau vdev.

Faut-il utiliser ashift=12 pour les disques 4K ?

Cette valeur représente généralement un alignement de 4K, mais validez le comportement du périphérique et les recommandations actuelles d’OpenZFS.

Une capacité différente est-elle importante ?

Un miroir est limité par son membre le plus petit, et un remplacement annoncé peut être légèrement plus petit.

Pour un miroir ZFS à secteurs mixtes, la réponse pratique reste conditionnelle : le remplacement est attaché, la reconstruction est terminée et la latence des écritures alignées reste acceptable. Lorsque l’ashift est trop petit, que le remplacement est légèrement plus petit ou que les performances se dégradent avec les écritures synchrones et aléatoires, utilisez un remplacement adapté ou reconstruisez un nouveau pool correctement aligné plutôt que de forcer l’utilisation d’un disque trop petit ; une réussite partielle qui ne résiste pas à la charge de travail initiale n’est pas une compatibilité.