El tl; dr: ¿cómo haría para arreglar un bloque defectuoso en 1 disco en una matriz RAID1?
Pero lea todo esto por lo que ya he probado y posibles errores en mis métodos. He tratado de ser lo más detallado posible, y realmente espero algún comentario
Esta es mi situación: tengo dos discos de 2TB (mismo modelo) configurados en una matriz RAID1 administrada por mdadm
. Hace unos 6 meses, noté el primer bloqueo incorrecto cuando SMART lo informó. Hoy noté más, y ahora estoy tratando de arreglarlo.
Esta página de CÓMO parece ser el único artículo al que todos se vinculan para reparar los 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 con un solo disco en mente, 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 es compatible. He estado usando gdisk en su lugar, y espero que me esté dando la misma información que necesito
Entonces, pongámonos manos a la obra. Esto es lo que he hecho, sin embargo, no parece estar funcionando. Por favor, siéntase libre de verificar mis cálculos y método para detectar errores. El disco que informa errores es / 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 es compatible con 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 tunefs
encuentro el blockize ser 4096
. Usando esta información y el cálculo del CÓMO, concluyo que el bloque en cuestión es ((3212761936 - 2048) * 512) / 4096 = 401594986
.
Luego, el CÓMO me dirige debugfs
a ver 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 escribirle, trato de asegurarme de que, de hecho, 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 funcione. Sin embargo, lo hace. Repito usando /dev/sda
, /dev/sda1
, /dev/sdb
, /dev/sdb1
, /dev/md0
, y + -5 al número de bloque para buscar en todo el bloque defectuoso. Todo funciona Me encojo de hombros y sigo escribiendo y sincronizando (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 escribir en el bloque incorrecto haga que los discos reasignen el bloque a uno bueno, sin embargo, ejecutar otra prueba SMART muestra de manera diferente:
# 1 Short offline Completed: read failure 90% 12170 3212761936
De vuelta al cuadro 1. Entonces, ¿cómo solucionaría un bloque defectuoso en 1 disco en una matriz RAID1? Estoy seguro de que no he hecho algo correctamente ...
Gracias por su tiempo y paciencia.
EDITAR 1:
Intenté ejecutar una prueba SMART larga, con el mismo LBA regresando como malo (la única diferencia es que informa que queda un 30% en lugar del 90%):
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 30% 12180 3212761936
# 2 Short offline Completed: read failure 90% 12170 3212761936
También he usado badblocks con el siguiente resultado. El resultado es extraño y parece tener un formato incorrecto, pero intenté probar los números que salen como bloques, pero debugfs da un error
# badblocks -sv /dev/sda
Checking blocks 0 to 1953514583
Checking for bad blocks (read-only test): 1606380968ne, 3:57:08 elapsed. (0/0/0 errors)
1606380969ne, 3:57:39 elapsed. (1/0/0 errors)
1606380970ne, 3:58:11 elapsed. (2/0/0 errors)
1606380971ne, 3:58:43 elapsed. (3/0/0 errors)
done
Pass completed, 4 bad blocks found. (4/0/0 errors)
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 1606380968
Illegal block number passed to ext2fs_test_block_bitmap #1606380968 for block bitmap for /dev/md0
Block 1606380968 not in use
No estoy seguro de a dónde ir desde aquí. badblocks
Definitivamente encontré algo, pero no estoy seguro de qué hacer con la información presentada ...
EDITAR 2
Más comandos e información.
Me siento como un idiota olvidando incluir esto originalmente. Estos son valores SMART para /dev/sda
. Tengo 1 Current_Pending_Sector y 0 Offline_Uncorrectable.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 166
2 Throughput_Performance 0x0026 055 055 000 Old_age Always - 18345
3 Spin_Up_Time 0x0023 084 068 025 Pre-fail Always - 5078
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 75
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 12224
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 75
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 1646911
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 12
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 064 059 000 Old_age Always - 36 (Min/Max 22/41)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0030 252 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 30
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 77
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu May 5 06:30:21 2011
Raid Level : raid1
Array Size : 1953512383 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953512383 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Jul 3 22:15:51 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : server:0 (local to host server)
UUID : e7ebaefd:e05c9d6e:3b558391:9b131afb
Events : 67889
Number Major Minor RaidDevice State
2 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
Según una de las respuestas: parece que cambié seek
y skip
para dd
. Estaba usando la búsqueda ya que eso es lo que se usa con el CÓMO. El uso de este comando hace dd
que se cuelgue: # dd if = / dev / sda1 of = / dev / null bs = 4096 count = 1 skip = 401594986
El uso de bloques alrededor de ese (..84, ..85, ..87, ..88) parece funcionar bien, y el uso de / dev / sdb1 con 401594986
lecturas de bloque también está bien (como se esperaba, ya que ese disco pasó la prueba SMART ) Ahora, la pregunta que tengo es: al escribir sobre esta área para reasignar los bloques, ¿uso /dev/sda1
o /dev/md0
? No quiero causar ningún problema con la matriz RAID al escribir directamente en un disco y no tener la otra actualización de disco.
EDITAR 3
Escribir en el bloque produjo directamente errores en el sistema de archivos. Elegí una respuesta que resolvió el problema rápidamente:
# 1 Short offline Completed without error 00% 14211 -
# 2 Extended offline Completed: read failure 30% 12244 3212761936
Gracias a todos los que ayudaron. =)
/sbin/badblocks -sv /dev/sda
revisar el disco.
sudo mdadm -D /dev/md0
smartctl -t long /dev/sda
y ver si cambia el LBA del primer error.