El tl;dr: ¿cómo haría para arreglar un bloque defectuoso en 1 disco en una matriz RAID1?
Pero lea todo esto para conocer lo que ya he probado y los posibles errores en mis métodos. Intenté ser lo más detallado posible y realmente espero recibir comentarios.
Esta es mi situación: tengo dos discos de 2 TB (mismo modelo) configurados en una matriz RAID1 administrada por mdadm. Hace aproximadamente 6 meses noté el primer bloque defectuoso cuando SMART lo informó. Hoy noté más y ahora estoy tratando de solucionarlo.
Esta página CÓMOParece ser el único artículo al que todos se vinculan para corregir bloques defectuosos que SMART informa. Es una gran página, llena de información, sin embargo, está bastante desactualizada y no aborda mi configuración particular. Así es como mi configuración es diferente:
- En lugar de un disco, estoy usando dos discos en una matriz RAID1. Un disco informa errores mientras que el otro está bien. El CÓMO está escrito pensando en un solo disco, lo que plantea varias preguntas como "¿uso este comando en el dispositivo de disco o en el dispositivo RAID"?
- Estoy usando GPT, que fdisk no admite. He estado usando gdisk en su lugar y espero que me brinde la misma información que necesito.
Entonces, vayamos al grano. Esto es lo que he hecho, sin embargo, no parece estar funcionando. No dude en volver a verificar mis cálculos y método para detectar errores. Los errores de informe del disco son /dev/sda:
# smartctl -l selftest /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.4.4-2-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 12169 3212761936
Con esto, deducimos que el error reside en LBA 3212761936. Siguiendo el CÓMO, uso gdisk para encontrar el sector de inicio que se usará más adelante para determinar el número de bloque (ya que no puedo usar fdisk ya que no admite GPT):
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): CFB87C67-1993-4517-8301-76E16BBEA901
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 3907029134 1.8 TiB FD00 Linux RAID
Usando tunefsencuentro que el tamaño del bloque es 4096. Usando esta información y el cálculo del COMO, concluyo que el bloque en cuestión es ((3212761936 - 2048) * 512) / 4096 = 401594986.
Luego, el CÓMO me dirige a debugfsver si el bloque está en uso (uso el dispositivo RAID ya que necesita un sistema de archivos EXT, este fue uno de los comandos que me confundió ya que, al principio, no sabía si debía usar / dev/sda o /dev/md0):
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 401594986
Block 401594986 not in use
Entonces el bloque 401594986 es un espacio vacío, debería poder escribir sobre él sin problemas. Sin embargo, antes de escribirlo, trato de asegurarme de que, efectivamente, no se pueda leer:
# dd if=/dev/sda1 of=/dev/null bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000198887 s, 20.6 MB/s
Si el bloque no se pudiera leer, no esperaría que esto funcionara. Sin embargo, lo hace. Repito usando /dev/sda, /dev/sda1, /dev/sdb, /dev/sdb1, /dev/md0y +-5 en el número de bloque para buscar alrededor del bloque defectuoso. Todo funciona. Me encojo de hombros y sigo adelante y comprometo la escritura y sincronización (uso /dev/md0 porque pensé que modificar un disco y no el otro podría causar problemas, de esta manera ambos discos sobrescriben el bloque defectuoso):
# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000142366 s, 28.8 MB/s
# sync
Esperaría que al escribir en el bloque defectuoso los discos reasignen el bloque a uno bueno; sin embargo, al ejecutar otra prueba SMART se muestra de manera diferente:
# 1 Short offline Completed: read failure 90% 12170 3212761936
Volvamos al punto 1. Básicamente, ¿cómo arreglaría un bloque defectuoso en 1 disco en una matriz RAID1? Seguro que no he hecho algo correctamente...
Gracias por su tiempo y paciencia.