Ejecuto Ubuntu 22.04 en una máquina con tres RAID de software de diferente tamaño y geometría, dos de ellos (se llaman md5y md6) muy grandes. Los discos se comparten entre estos arreglos por ciertas razones.
Cada mes, cronse inicia automáticamente una nueva verificación de las matrices RAID del software. Debido a los discos compartidos, sólo se puede ejecutar una de las tres comprobaciones RAID en un momento dado; las otras se pausan automáticamente. Además, la nueva verificación se realiza solo durante seis horas cada día, aunque no sé cómo se determina el comienzo de ese período de seis horas.
El sistema de archivos se montó desde que md6se congeló, cuando se interrumpió la nueva verificación md6el segundo día. Todos los procesos y subprocesos con lecturas y escrituras en ese sistema de archivos quedaron atrapados en "suspensión ininterrumpida". Tampoco fue posible forzar el desmontaje o desmontaje de la matriz, por lo que tuve que reiniciar para acceder a mis datos nuevamente. Aparte del eficaz DOS, no parece que se haya perdido ningún dato.
En el registro, veo que sucede lo siguiente: el primer día, la verificación de las tres matrices se inicia al mismo tiempo. La matriz más pequeña md1, gana la carrera por ver quién se controla primero, mientras que md5tiene md6que esperar. md1termina en menos de diez minutos y luego md6continúa hasta el final del día 1.
El día 2, md5(¡no el que ya comenzó md6!) Gana la carrera por quién se controla. Después de seis horas, se interrumpe el control md5del día. md6, que aparentemente recibió el comando "ejecutar" unos milisegundos más tarde, comienza a funcionar, solo para recibir la parada de 6 horas dentro del mismo segundo en el que comenzó.
Después de ese inicio y parada súper rápido de la verificación md6, md6se congela. La primera señal de esto en el registro es una advertencia de que un intento de escribir en el diario del sistema de archivos ha sido bloqueado durante más de dos minutos:
Aquí las partes relevantes del registro ("M" es el nombre de la máquina):
Sep 4 08:23:59 M root: mdcheck start checking /dev/md1
Sep 4 08:23:59 M kernel: [1682166.084604] md: data-check of RAID array md1
Sep 4 08:24:00 M root: mdcheck start checking /dev/md5
Sep 4 08:24:00 M kernel: [1682167.725977] md: delaying data-check of md5 until md1 has finished (they share one or more physical units)
Sep 4 08:24:00 M root: mdcheck start checking /dev/md6
Sep 4 08:24:00 M kernel: [1682167.758063] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 4 08:33:23 M kernel: [1682730.686726] md: md1: data-check done.
Sep 4 08:33:23 M kernel: [1682730.697864] md: data-check of RAID array md6
Sep 4 08:33:23 M kernel: [1682730.697864] md: delaying data-check of md5 until md6 has finished (they share one or more physical units)
Sep 4 08:34:01 M root: mdcheck finished checking /dev/md1
Sep 4 14:24:02 M root: pause checking /dev/md5 at 0
Sep 4 14:24:03 M kernel: [1703770.476375] md: md6: data-check interrupted.
Sep 4 14:24:03 M root: pause checking /dev/md6 at 5702160936
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Deactivated successfully.
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Consumed 1.957s CPU time.
Sep 4 20:03:05 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md5 from 0
Sep 5 07:02:14 M kernel: [1763663.944043] md: data-check of RAID array md5
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md6 from 5702160936
Sep 5 07:02:14 M kernel: [1763663.980271] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 5 13:02:26 M kernel: [1785276.510597] md: md5: data-check interrupted.
Sep 5 13:02:27 M kernel: [1785276.786479] md: data-check of RAID array md6
Sep 5 13:02:27 M root: pause checking /dev/md5 at 5824508144
Sep 5 13:02:27 M kernel: [1785276.795438] md: md6: data-check interrupted.
Sep 5 13:05:31 M kernel: [1785461.181277] INFO: task jbd2/md6-8:2495 blocked for more than 120 seconds.
Sep 5 13:05:31 M kernel: [1785461.181441] task:jbd2/md6-8 state:D stack: 0 pid: 2495 ppid: 2 flags:0x00004000
Sep 5 13:05:31 M kernel: [1785461.181742] md_write_start.part.0+0x174/0x220
Sep 5 13:05:31 M kernel: [1785461.181753] md_write_start+0x14/0x30
Sep 5 13:05:31 M kernel: [1785461.181781] md_handle_request+0x12d/0x1b0
Sep 5 13:05:31 M kernel: [1785461.181792] md_submit_bio+0x71/0xc0
Sep 5 14:44:14 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Debido a que /los /homesistemas de archivos están en RAID no afectados, aún podría iniciar sesión después de congelar md6. cat /proc/mdstatdio la siguiente información:
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md5 : active raid5 sdd4[1] sdk4[2] sdh4[0] sdl4[4]
11415389184 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/29 pages [0KB], 65536KB chunk
md1 : active raid1 sdd3[0] sdk3[1] sdh3[3] sdl3[2]
100596736 blocks super 1.2 [4/4] [UUUU]
md6 : active raid6 sdd2[10] sdk2[9] sdh2[11] sdl2[8] sdg[5] sdf[4] sdb[1] sdc[2] sdi[6] sde[3] sdj[7] sda[0]
117186867200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
[====>................] check = 24.3% (2851080676/11718686720) finish=95845361544.0min speed=0K/sec
bitmap: 0/88 pages [0KB], 65536KB chunk
Tenga en cuenta que eso /proc/mdstatparece devolver la posición de la nueva verificación en bloques de 1 kB con 2851080676 igual a 5702161352 sectores, que está a solo 416 sectores (¡menos de un fragmento!) del 5702160936 registrado syslogcomo posición alcanzada el día anterior. . Por lo tanto, asumo un punto muerto en la verificación iniciada y luego detenida inmediatamente nuevamente.
Mi mitigación hasta ahora ha sido desactivar la verificación automática de MD RAID.
Respuesta1
Es posible que te encuentres con este error:https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935. Es un error del kernel ascendente con parches para solucionarlo en Linux v5.19.
Decomentario 10, puede probar esta solución (cambie primero md1a md5/ md6/etc.):
echo active | sudo tee /sys/block/md1/md/array_state