Mostrando las entradas con la etiqueta HDD. Mostrar todas las entradas
Mostrando las entradas con la etiqueta HDD. Mostrar todas las entradas

lunes, 9 de julio de 2012

Recambio de disco RAID1 en SB850 softRAID

Hardware

Equipo de escritorio con Placa Madre Asus M4A89TD PRO - Chipset AMD SB850. El chipset soporta Raid de mentirita (AKA fakeRAID). Tiene dos discos haciendo RAID1 (espejado). Como se puede ver en los artículos específicos, el fakeRAID de la controladora muy poco por la conformación del RAID, ya que el trabajo de sincronización lo hace el procesador principal.

Software

Ubuntu 10.04.4 LTS, Linux 2.6.32. Ubuntu viene con dmraid instalado. La instalación resultó muy sencilla.

El problema, comportamiento

Al iniciar sesión los usuarios demoraban mucho tiempo en poder lanzar aplicaciones. Luego podían trabajar normalmente hasta que sin causa clara en un momento las aplicaciones no respondían con un comportamiento típico de bloqueo de espera activa. Los bloqueos no discriminaban inicios de sesión GUIs, etc. Anulé la ejecución de algunos demonios suponiendo que en cada arranque bloqueaban entrada/salida de disco, ya que no se apreciaban abusos de memoria RAM, iotop tampoco acusaba un gran caudal de tránsito de datos.

El kernel mataba a algunos procesos porque se bloqueaban
Jun 13 09:55:57 melezca kernel: [  961.870114] INFO: task dpkg:2667 blocked for more than 120 seconds.
Jun 13 09:55:57 melezca kernel: [  961.870122] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 13 09:55:57 melezca kernel: [  961.870129] dpkg          D 0000000000000000     0  2667   2638 0x00000000
Jun 13 09:55:57 melezca kernel: [  961.870141]  ffff8800bd6f1de8 0000000000000086 0000000000015c00 0000000000015c00
Jun 13 09:55:57 melezca kernel: [  961.870152]  ffff88011a2c9aa8 ffff8800bd6f1fd8 0000000000015c00 ffff88011a2c96f0
Jun 13 09:55:57 melezca kernel: [  961.870160]  0000000000015c00 ffff8800bd6f1fd8 0000000000015c00 ffff88011a2c9aa8
Jun 13 09:55:57 melezca kernel: [  961.870169] Call Trace:
Jun 13 09:55:57 melezca kernel: [  961.870186]  [] jbd2_log_wait_commit+0xc5/0x150
Jun 13 09:55:57 melezca kernel: [  961.870197]  [] ? flush_cpu_workqueue+0x4e/0xa0
Jun 13 09:55:57 melezca kernel: [  961.870206]  [] ? autoremove_wake_function+0x0/0x40
Jun 13 09:55:57 melezca kernel: [  961.870214]  [] ? _spin_lock+0xe/0x20
Jun 13 09:55:57 melezca kernel: [  961.870223]  [] ext4_sync_fs+0x7f/0xb0
Jun 13 09:55:57 melezca kernel: [  961.870232]  [] sync_quota_sb+0x5e/0x130
Jun 13 09:55:57 melezca kernel: [  961.870241]  [] __sync_filesystem+0x7a/0x90
Jun 13 09:55:57 melezca kernel: [  961.870249]  [] sync_filesystems+0xd9/0x130
Jun 13 09:55:57 melezca kernel: [  961.870256]  [] sys_sync+0x21/0x40
Jun 13 09:55:57 melezca kernel: [  961.870266]  [] system_call_fastpath+0x16/0x1b

Causa

Uno de los discos del RAID estaba roto. S.M.A.R.T. arrancaba apagado, tal vez por la controladora. Al activarlo y leer los registros la entrada "197 - 0xC5 - Current Pending Sector Count" tenía un valor distinto de cero y variable con la actividad en el sistema de archivos.

Para constatar inicié el sistema, luego desconecté la ficha SATA del disco sospechoso (los drivers y la controladora admiten hotplug), y las asfixias se detuvieron.


La solución

Conceptualmente la solución sería comprar un disco igual, indicarle a "la controladora" que es un spare drive, desconectar el roto para para que migre el RAID al nuevo disco. Por desgracia ese ajuste no se puede hacer en el menú del BIOS y ni tampoco se pueden realizar estas operaciones con dmraid, porque no está portada totalmente para metadatos de Promise FastTrack.

La (nauseabunda) manera que encontré fue instalar windows en un cuarto disco IDE. Allí instalar RAIDXpert y realizar las operaciones mencionadas. AMD no provee manera de recomponer el RAID. :(

Conclusiones


  • Un disco puede estar afectando al sistema sin disparar alarmas de SMART, en ese sentido resulta oportuno verificar los registros 0xC5 de cada disco,
  • Aparentemente la controladora RAID desactiva SMART,
  • Hay actividades de mantenimiento muy livianas y esenciales que precisan de acceso a disco (login vía ssh), es tortuoso trabajar con el disco roto.
  • Los manuales de uso de los chipsets tienen información falsa. El manual actualizado de RAIDXpert indica como instalar y usarlo en Linux y no binario para Linux no existe.

martes, 14 de julio de 2009

Discos Duros y la mar en coche

Sucesos en los últimos 4 meses me han llevado a comprar disco duro, a cambiarlo y recambiarlo 4 veces, me hubiera gustado encontrarme alguna vez con una publicación que explique estas cosas triviales después de que uno las vive :-(

No es tan limitada la cantidad de marcas de discos

Me paso de comprar apurado no mirar y al llegar a casa encontrarme con un disco de una marca desconocida, que no tenía siquiera página web MediaMax, no soporte, no actualizaciones.

Los discos pueden fallar aunque no acusen sectores defectuosos (SMART)

La clave esta en leer los parámetos SMART, los discos contemporáneos tienen una zona reservada para reubicar sectores defectuosos, entonces al encontrar un sector defectuoso, éste se graba en la zona reservada. Un registro se incrementa en una unidad y esos datos y muchos otros se pueden leer via S.M.A.R.T. Un programa para leerlos es smartmontools y una GUI para éste es gsmartcontrol. En lo personal la GUI me parece muy cómoda, pero no lo veo cómodo para servers, las explicaciones del artículo de Wikipedia ayudan también.

dd no ayuda mucho para pruebas de fuerza bruta (secuencial vs bloque)

Dejé el 2do disco de cambio que ya era de una marca que conocía probando con lectura y escritura permanente con dd, en el disco en bruto. Sin embargo eso no alcanzó, porque aparentemente había un problema con el dimensionamiento del disco que hacía que el funcionamiento como dispositivo de bloque fallara, concretamente los problemas estaban al escribir archivos, y en la última de las particiones que me quedaba por copiar :(

badblocks -w demora y no dejarlo terminar puede dar problemas

Para probar más use badblocks escribiendo cosas, pero se demoraba tanto que lo interrumpí en alguna de las etapas, luego particioné, cree las particiones pero al momento de escribir archivos ya estaban llenas algunas de ellas? resulta que las secuencias de escrituras se confundían con alguna secuencia tipo "final" de archivo en FAT o que se yo qué que me obligó a llenar el disco de ceros nuevamente.