Comment puis-je vérifier les blocs défectueux sur un volume physique LVM?

Lorsque vous utilisez ext4, vous pouvez vérifier les badblocks avec la commande e2fsck -c /dev/sda1 # or whatever. Cela "mettra sur liste noire" les blocs en les ajoutant au mauvais inode de bloc.

Quel est l'équivalent de cela pour un volume physique LVM2? Le système de fichiers qu'il contient est ext4, mais il est probable que les blocs défectueux détectés deviendront invalides lorsque la configuration LVM sous-jacente déplace les données sur le disque physique.

En d'autres termes, comment puis-je vérifier les blocs défectueux à ne pas utiliser dans LVM?

Lorsque vous utilisez ext4, vous pouvez vérifier les badblocks avec la commande e2fsck -c /dev/sda1ou autre chose. Cela "mettra sur liste noire" les blocs en les ajoutant au mauvais inode de bloc.

e2fsck -cs'exécute badblockssur le disque dur sous-jacent. Vous pouvez utiliser la badblockscommande directement sur un volume physique LVM (en supposant que le PV est en fait un disque dur, et non un autre type de périphérique virtuel comme un périphérique RAID logiciel MD), tout comme vous utiliseriez cette commande sur un disque dur qui contient un système de fichiers ext.

Cela n'ajoutera aucune sorte d'informations de blocage incorrectes au système de fichiers, mais je ne pense pas vraiment que ce soit une fonctionnalité utile du système de fichiers; le disque dur est censé gérer les blocs défectueux.

Encore mieux que l' badblocksexécution d'un autotest SMART sur le disque (remplacez-le /dev/sdXpar le nom de périphérique de votre disque dur):

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

Le test lui-même prendra quelques heures (il vous dira exactement combien de temps). Une fois terminé, vous pouvez interroger le résultat avec smartctl -a, recherchez le journal d'autotest. S'il indique "Terminé avec succès", votre disque dur fonctionne bien.

En d'autres termes, comment puis-je vérifier les blocs défectueux à ne pas utiliser dans LVM?

Comme je l'ai dit, le disque dur lui-même garantira qu'il n'utilisera pas de blocs endommagés et il déplacera également les données de ces blocs; ce n'est pas quelque chose que le système de fichiers ou le LV doit faire. D'un autre côté, lorsque votre disque dur contient plus que quelques blocs défectueux, vous ne voulez pas quelque chose qui les déplace, mais vous voulez remplacer tout le disque dur car il échoue.

Je suis presque sûr que LVM ne gère pas les mauvais blocs; il attend le stockage sous-jacent. Et la plupart, sinon la totalité, des disques durs modernes le font. Vous devrez peut-être effectuer une écriture dans le secteur, mais le disque doit le remapper. (Vous en aurez peut-être besoin pour effectuer une analyse de surface hors ligne, par exemple avec smartctl /dev/sda -t offline).

Cela dit, LVM ne déplace pas réellement les données sauf si vous le demandez, par exemple avec pvmove. Vous pouvez donc utiliser la fonction badblocks ext4; il vous suffira de revérifier les blocs défectueux s'il est exécuté pvmove. Aucune opération courante (telle que lvextend) ne déplace les données.

Extend ne déplace pas les données car LVM conserve une carte indiquant "les extensions logiques 0–99 sont des extensions physiques 200–299", puis lorsque vous les étendez, il ajoute simplement "les extensions logiques 100–199 sont des extensions physiques 100–199". Ou même «les étendues logiques 100 à 149 sont des étendues physiques 50 à 99; les étendues logiques 150 à 199 sont des étendues physiques 140 à 189». LVM ne se soucie pas que les étendues physiques ne soient pas en ordre ou ne soient pas contiguës.

pvckpeut vérifier les métadonnées LVM, après que la cohérence est le travail du système de fichiers. LVM ne concerne que la gestion du volume, il n'a donc pas besoin de se soucier si l'espace constituant une étendue particulière est mauvais car un logiciel de niveau supérieur détecte ces problèmes. Les métadonnées LVM n'occupent de toute façon que le premier (éventuellement aussi le dernier secteur) du volume physique.

Si seulement le premier et le dernier secteurs d'un PV raisonnablement grand (comme celui que vous voyez en production) échouent simultanément, vous avez essentiellement la chance la plus merdique au monde, car c'est tellement improbable sur le plan astronomique. Sinon, si l'administrateur sait que plusieurs secteurs du lecteur ont échoué, la plupart des gens sont d'accord avec simplement le dépôt de ces choses sous "le disque dur a échoué de façon permanente et doit être remplacé".

Si pvckrenvoie une erreur, vous pouvez vérifier si vos métadonnées LVM sont sauvegardées /etc/lvmquelque part. Si c'est le cas, vous pouvez pvcreatespécifier la copie de sauvegarde--restorefile

Syntaxe:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Exemple:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

Si la restauration ne fonctionne pas (par exemple, si le premier secteur est défectueux), vous pouvez refaire ce qui précède, mais définissez --metadatacopies 2(ou vous pouvez simplement y aller directement) qui tentera d'écrire les métadonnées dans le premier et derniers secteurs sur le PV. Quand pvscanfait son truc au démarrage, il vérifiera les deux endroits et s'il trouve des métadonnées, il les vérifiera par rapport à une somme de contrôle. Si la somme de contrôle échoue sur le premier secteur mais réussit sur le dernier secteur, vous obtiendrez un message d'erreur non fatal.

Type de manuel et une douleur, mais là encore, cela fait partie de la raison pour laquelle les gens sont ravis d'obtenir une gestion de volume redux avec BTRFS. La plupart du temps, ce n'est pas vraiment un problème pour les raisons mentionnées par Derobert, et parce que les personnes qui ont absolument besoin d'assurer la continuité des données feront généralement du RAID et auront une stratégie de sauvegarde.