Acabo de descubrir el mismo problema en dos servidores nuevos e idénticos instalados hace sólo 9 meses. No pude escribir en el disco de ninguno de los dos porque el sistema lo había marcado como de sólo lectura. Los registros indicaron que hubo algún tipo de error de disco en ambos.
Tenga en cuenta que estoy ejecutando KVM con varios invitados en cada uno de estos servidores. Todos los invitados funcionaban bien, pero el problema estaba en el host KVM. Probablemente esto no importe, pero tal vez sí lo sea. Ambos sistemas tienen sólodos unidadescon software raid1 y LVM encima. Cada invitado KVM también tiene su propia partición LVM.
Ambos sistemas mostraban una matriz RAID1 degradada al observarlos /proc/mdstat.
Entonces reinicié uno de los sistemas y me dijo que necesitaba ejecutarlo manualmente fsck. Entonces lo hice. Pareció solucionar los problemas y al reiniciar el sistema volvió a funcionar normalmente. El mismo proceso también funcionó en el segundo servidor.
Luego corrí mdadm --manage /dev/md0 --add /dev/sdb1para volver a agregar la unidad fallida a la matriz. Esto funcionó bien en ambos servidores. Durante la siguiente hora más o menos, la observación mostró que /proc/mdstatse estaba avanzando en la sincronización de las unidades. Después de aproximadamente una hora, un sistema finalizó y /proc/mdstatmostró que todo funcionaba bien [UU].
Sin embargo, en el otro sistema, después de aproximadamente 1,5 horas, la carga del sistema se disparó y nada respondía. Unos minutos más tarde, todo volvió. Pero mirar /proc/mdstatahora muestra lo siguiente:
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
Como puede ver, parece que ya no se sincroniza. Ya no se muestra el porcentaje completado, el tiempo restante, etc. Sin embargo, al ejecutar mdadm --detail /dev/md0se muestra esto:
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
La conclusión parece indicar que el repuesto se está reconstruyendo. ¿Por qué es un repuesto? El sistema informa que ambos dispositivos están limpios. Ha estado así durante horas. Las unidades son VelociRaptors pequeños y rápidos de 300 GB y 10K RPM, por lo que creo que ya se habrían sincronizado. Al intentar volver a agregar, dice que el dispositivo está ocupado:
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
Al ejecutar dmesg en el servidor "bueno" se muestra esto al final:
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
En el servidor "malo", esas últimas 4 líneas se repiten cientos de veces. En el servidor "bueno", sólo se muestran una vez.
¿Las unidades siguen sincronizándose? ¿Terminará esta "reconstrucción"? ¿Necesito ser más paciente? Si no, ¿qué debo hacer ahora?
ACTUALIZAR:
Simplemente reinicié y la unidad comenzó a sincronizarse nuevamente. Después de casi 2 horas, sucedió lo mismo que se describe anteriormente (aún aparece un [_U]). Sin embargo, pude ver los registros de dmesg antes de que los fragmentos de impresión de la configuración RAID1 lo consumieran todo:
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
Entonces, tal vez la pregunta que debería hacerme es "¿Cómo ejecuto fsck en un disco de repuesto en un conjunto raid?"
Respuesta1
No tengo claro si realmente reemplazó las unidades defectuosas. Porque para mí sus síntomas tendrían sentido si hubiera vuelto a agregar la unidad defectuosa, en cuyo caso es muy probable que la unidad se haya bloqueado. Si volvió a agregar la unidad defectuosa, ¿hay errores posteriores en /var/log/messages o dmesg?
(Por cierto, recomiendo encarecidamente no volver a agregar una unidad defectuosa a una matriz RAID. Si la falla dañó los datos en el plato, es posible que cuando lo agregue de nuevo a la matriz, la resincronización deje el archivo dañado en el disco, y la próxima vez que lea los archivos, será complicado saber si obtiene datos buenos o malos, dependiendo de qué disco responda primero; he visto que esto suceda en la naturaleza).
Respuesta2
El uso de mdadm --details incluirá una unidad como repuesto mientras se reconstruye. Una vez completada la reconstrucción, ya no aparecerá como repuesto.
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
La primera línea indica que hubo un error de reasignación y que los datos no se leyeron. Las siguientes tres líneas señalan que los datos no se pudieron leer y enumeran los sectores que no se pueden leer.
Como señaló Rodger, el disco está defectuoso, no lo vuelva a agregar. Nunca es una buena idea volver a agregar una unidad que falló. Tire de la unidad y reemplácela. Si lo desea, ejecute diagnósticos en la unidad fallida, pero solo después de haberla extraído y reemplazado.
Respuesta3
Primero, sí, elimine cualquier disco que arroje errores de lectura que terminen en el archivo de registro. Esto significa que la reubicación del bloque defectuoso ha fallado y/o que la unidad está a punto de morir.
Le sugiero que para rescatar sus datos utilice un CD de rescate de Linux comohttp://ubuntu-rescue-remix.org/para usar ddrescue. Esto puede hacer una copia de la imagen en la partición de un disco nuevo y realizará muchos reintentos, etc., para intentar recuperar su partición. Montar una unidad USB u otra partición
mkdir /tmp/x && montar /dev/sdd1 /tmp/x
para contener el archivo de registro de ddrescue; luego puede detener el ddrescue (ctrl-C) y reiniciarlo más tarde desde el mismo punto.
Haga una partición en el disco nuevo un poco más grande que el disco antiguo. ¡No es necesario utilizar todo el disco!
Inicie el CD de rescate con "nodmraid" como parámetro de inicio del kernel. Si usa ubuntu live CD, instale RAID y LVM si lo está usando
apt-get instala mdadm lvm2 gddrescue
necesitarás estar en Internet para que esto funcione). De lo contrario, utilice el CD de rescate de Ubuntu para el paso ddrescue. Cambié entre el CD de rescate para ejecuciones de ddrescue y el CD en vivo para el trabajo de grub y fsck.
Suponiendo que /dev/sdb es su disco de origen defectuoso, y /dev/sdx es su nuevo disco, y /mnt/x es una llave USB o una partición en otro disco que se ha montado. Túnecesidadel archivo de registro ddrescue, ¡de verdad! Ya que rastrea cómo va ddrescue y permite que se interrumpa.
segúnhttp://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX archivo de imagen /mnt/x/logfile
entonces
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
entonces
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
No tenga miedo de presionar Ctrl-C en el proceso si lleva horas recuperar un solo sector. Simplemente continúe con el siguiente paso (el paso 1 debería tener éxito pase lo que pase). El último paso intenta recuperar los últimos restos de datos utilizables.
También tendrás que hacer
mdadm --create /dev/md99 --level-1 --raid-devices=2 falta /dev/sdX
Para crear una nueva matriz RAID usando el nuevo disco, esto escribe un nuevo superbloque RAID en la partición (en los últimos 64K a 128K al final de la partición).
Elimine su antiguo disco defectuoso /dev/sdb del sistema para que no sea visible para Linux.
Haga accesible su disco RAID de origen. Es posible que tengas que usar el parámetro "nodmraid" para el kernel de arranque, ya que tuve problemas con el CD de rescate de Ubuntu y terminé usando el Live CD de Ubuntu (10.4), donde nodmraid está en Opciones de F6. Sólo deberías necesitar usar
mdadm --ensamblar /dev/md99 /dev/sdX
Luego fsck o haga cualquier verificación que necesite hacer con los datos en la matriz RAID md99 (usé vgscan y luego pude ver los LV de LVM para ejecutar la verificación). Utilizo XFS para Mytv, pero el comando xfs_check bloqueó mi sistema, pero xfs_repair estaba bien.
Monte el directorio /boot desde su nuevo /dev/sdX
montar /dev/mapper/my_vg/root_lv /tmp/x
luego coloque un nuevo registro de arranque de GRUB en el nuevo disco RAID /dev/sdX (¡solo si arranca desde RAID!)
configuración-grub -d /tmp/x/boot/grub /dev/sdX
ahora tiene una matriz RAID (casi) de arranque. También puede realizar la configuración usando GRUB o usar dd para copiar los primeros 446 bytes de /dev/sdb a /dev/sdX. ¡SÓLO los primeros 446 bytes, el resto del primer sector es su tabla de particiones, que llenará enormemente si copia más! Es posible que también tengas que hacer lo mismo para el primer sector de tu partición /dev/sdX1 (por ejemplo). Haga una copia de seguridad de los sectores que vaya a sobrescribir, utilizando también dd.
Si usa grub2 y está iniciando desde RAID, encontrará que el UUID de la matriz RAID ha cambiado, por lo que su inicio fallará. Edite la línea de comando de inicio (e en el panel de inicio de Grub) para eliminar el inicio y el silencio, para que pueda ver lo que está sucediendo. Luego, después del arranque fallido, quedará en initramfs.
mdadm --ensamblar /dev/md99 /dev/sdX
luego verifique /proc/mdstat para asegurarse de que la matriz esté allí. Si es así, simplemente "salga" y, con suerte, su sección de arranque de GRUB funcionará bien (la mía estaba configurada para usar LVM, por lo que simplemente encontró los LV en el dispositivo RAID una vez que hubo algún dispositivo RAID allí, simplemente buscó el LV). Una vez que haya iniciado, casi habrá terminado.
El archivo de imagen initrd (archivo cpio comprimido con gzip) contiene una copia de mdadm.conf utilizado durante el proceso de inicio, visible y editable como /etc/mdadm/mdamdm.conf durante el proceso de inicio. Si puede hacer que su sistema arranque normalmente, simplemente actualice initramfs usando
actualización-initramfs -u
Si no puede iniciar el sistema debido a que el UUID no coincide en el archivo mdadm.conf
Tenga en cuenta que su dispositivo de destino /dev/sdX puede aparecer como /dev/sdY cuando inicia de una manera diferente (Grub, rescate, inicio real).
Por cierto, a menos que estés usando RAID5 y estés realmente interesado en la alineación de bloques, usaría una partición para tu matriz RAID, no tienes que usar un disco completo (especialmente si estás reemplazando un disco de 1TB por uno de 2TB). uno). Siempre puede agregar otra partición y una segunda matriz RAID más adelante para utilizar los 2 TB completos.
¡Uf! ¡Hecho!