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.

5 comentarios:

Anónimo dijo...

Me recuerda a un similar problema que tuve con mi raid de discos. Luego de incontables horas buscando una solucion, termine llevando los discos a un laboratorio de recuperaciones. Onretrieval, de nombre...

CruX dijo...

fakeRAID es mala palabra, sobre todo si vas a usarlo bajo Linux. Hace/te un favor y reemplazá ese setup por mdadm. El trabajo de RAID lo va a seguir haciendo el CPU, pero con código dentro del kernel.

rock3r dijo...

Hola, en teoria el raidxpert soporta Linux.
Fuente: http://www2.ati.com/relnotes/AMD_RAIDXpert_User_v2.1.pdf

MAbeeTT dijo...

@rock3r no hay aplicación disponible para linux.

MAbeeTT dijo...

@CruX en ese momento no tenía otra opción, ya que la configuración ya la había hecho. Confiaba (equivocadamente) que el RAID de la placa era algo más decente.

Por otro lado, la idea de cambiar un disco por otro sin intervenciones especiales me fascina, como suele suceder con las mentiras.