¿Cómo puedo verificar si hay bloques defectuosos en un volumen físico LVM?

Cuando usa ext4, puede verificar si hay bloques defectuosos con el comando e2fsck -c /dev/sda1 # or whatever. Esto "pondrá en una lista negra" los bloques agregándolos al inodo del bloque defectuoso.

¿Cuál es el equivalente de esto para un volumen físico LVM2? El sistema de archivos en él es ext4, pero presumiblemente, los bloques defectuosos que se detecten serán inválidos a medida que la configuración LVM subyacente mueva los datos en el disco físico.

En otras palabras, ¿cómo puedo verificar si los bloques defectuosos no se usan en LVM?

Cuando usa ext4, puede verificar si hay bloques defectuosos con el comando e2fsck -c /dev/sda1o lo que sea. Esto "pondrá en una lista negra" los bloques agregándolos al inodo del bloque defectuoso.

e2fsck -cse ejecuta badblocksen el disco duro subyacente. Puede usar el badblockscomando directamente en un volumen físico LVM (suponiendo que el PV es en realidad un disco duro, y no algún otro tipo de dispositivo virtual como un dispositivo RAID de software MD), tal como usaría ese comando en un disco duro que contiene un sistema de archivos ext.

Eso no agregará ningún tipo de información de bloques defectuosos al sistema de archivos, pero realmente no creo que sea una característica útil del sistema de archivos; se supone que el disco duro maneja bloques defectuosos.

Incluso mejor que badblocksejecutar una autocomprobación SMART en el disco (reemplazar /dev/sdXcon el nombre del dispositivo de su disco duro):

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

La prueba sí tomará algunas horas (le dirá exactamente cuánto tiempo). Cuando termine, puede consultar el resultado con smartctl -a, buscar el registro de autocomprobación. Si dice "Completado con éxito", su disco duro está bien.

En otras palabras, ¿cómo puedo verificar si los bloques defectuosos no se usan en LVM?

Como dije, el disco duro mismo asegurará que no use bloques dañados y también reubicará los datos de esos bloques; eso no es algo que el sistema de archivos o el LV tiene que hacer. Por otro lado, cuando su disco duro tiene más que unos pocos bloques defectuosos, no desea algo que los reubique, pero desea reemplazar todo el disco duro porque está fallando.

Estoy bastante seguro de que LVM no maneja bloques malos; espera que el almacenamiento subyacente lo haga. Y la mayoría, si no todos, los discos duros modernos sí. Es posible que deba realizar una escritura en el sector, pero el disco debería reasignarlo. (Es posible que primero necesite hacer un escaneo de superficie fuera de línea, por ejemplo, con smartctl /dev/sda -t offline).

Dicho esto, LVM en realidad no mueve datos a menos que lo solicite, por ejemplo, con pvmove. Entonces puede usar la función ext4 badblocks; solo tendrá que volver a verificar si hay bloques defectuosos si se ejecuta pvmove. Ninguna operación común (como lvextend) mueve datos.

Extender no mueve datos porque LVM mantiene un mapa que dice "las extensiones lógicas 0–99 son extensiones físicas 200–299", y luego cuando lo extiende, simplemente agrega "las extensiones lógicas 100–199 son extensiones físicas 100–199". O incluso "las extensiones lógicas 100–149 son extensiones físicas 50–99; las extensiones lógicas 150–199 son extensiones físicas 140–189". A LVM no le importa que las extensiones físicas no estén en orden o no sean contiguas.

pvckpuede verificar los metadatos de LVM, luego de esa consistencia es el trabajo del sistema de archivos. LVM solo se trata de gestión de volumen, por lo que no necesita preocuparse si el espacio que constituye una extensión particular es malo, ya que el software de nivel superior detecta esos problemas. Los metadatos LVM solo ocupan el primero (opcionalmente también el último sector) del volumen físico de todos modos.

Si solo el primer y el último sector de un PV razonablemente grande (como se vería en la producción) fallan simultáneamente, básicamente tienes la mejor suerte del mundo, ya que es astronómicamente improbable. De lo contrario, si el administrador sabe que varios sectores de la unidad han fallado, la mayoría de la gente está de acuerdo con solo archivar cosas como esto en "la unidad de disco duro falló permanentemente y necesita ser reemplazada".

Si pvckdevuelve un error, puede verificar si sus metadatos LVM están respaldados en /etc/lvmalguna parte. Si es así, puede hacerlo pvcreateespecificando la copia de seguridad en--restorefile

Sintaxis:

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

Ejemplo:

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

Si la restauración no funciona (por ejemplo, si el primer sector es malo), puede volver a hacer lo anterior, pero establezca --metadatacopies 2(o simplemente vaya a hacerlo) que intentará escribir los metadatos en el primero y últimos sectores en el PV. Cuando pvscanhace lo suyo en el arranque, verificará ambos lugares y si encuentra metadatos, los verificará con una suma de verificación. Si la suma de comprobación falla en el primer sector pero tiene éxito en el último sector, recibirá un mensaje de error no fatal.

Tipo de manual y un dolor, pero, de nuevo, esto es parte de la razón por la cual las personas están entusiasmadas de obtener una reducción de gestión de volumen con BTRFS. La mayoría de las veces no es realmente un gran problema por las razones que mencionó derobert, y porque las personas que necesitan asegurar absolutamente la continuidad de los datos generalmente harán RAID y tendrán una estrategia de respaldo.