Eu executo o Ubuntu 22.04 em uma máquina com três RAIDs de software de tamanhos e geometrias diferentes, sendo dois deles (chamados md5e md6) muito grandes. Os discos são compartilhados entre essas matrizes por determinados motivos.
Todo mês, croninicia automaticamente uma nova verificação das matrizes RAID de software. Devido aos discos compartilhados, apenas uma das três verificações de RAID pode ser executada em um determinado momento, as outras são pausadas automaticamente. Além disso, a nova verificação é executada apenas durante seis horas por dia, embora eu não saiba como é determinado o início dessa janela de seis horas.
O sistema de arquivos montado md6congelou, quando a nova verificação foi interrompida md6no segundo dia. Todos os processos e threads com leituras e gravações nesse sistema de arquivos ficaram presos em "suspensão ininterrupta". A desmontagem ou desmontagem forçada do array também não foi possível, então tive que reinicializar para acessar meus dados novamente. Além do DOS eficaz, nenhum dado parece ter sido perdido.
No log, vejo o seguinte acontecendo: No primeiro dia, a verificação de todos os três arrays é iniciada ao mesmo tempo. A menor matriz, md1, vence a corrida para ver quem é verificado primeiro, enquanto md5e md6tem que esperar. md1termina em menos de dez minutos e md6continua até o final do dia 1.
No dia 2, md5(não o já iniciado md6!) Vence a corrida para quem for verificado. Após seis horas, a verificação md5do dia é interrompida. md6, que aparentemente recebeu o comando "run" alguns milissegundos depois, começa a rodar, apenas para receber a parada de 6 horas ainda no mesmo segundo em que foi iniciado.
Depois daquele start-stop super rápido da verificação md6, md6congela. O primeiro sinal disso no log é um aviso de que uma tentativa de gravação no diário do sistema de arquivos foi bloqueada por mais de dois minutos:
Aqui estão as partes relevantes do log ("M" é o nome da 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.
Como /os /homesistemas de arquivos estão em RAIDs não afetados, ainda consegui fazer logon após o congelamento do md6. cat /proc/mdstatdeu as seguintes informações:
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
Observe que isso /proc/mdstatparece retornar a posição da nova verificação em blocos de 1 kB com 2851080676 igual a 5702161352 setores, o que está a apenas 416 setores (menos de um pedaço!) de distância do 5702160936 logado syslogquando a posição alcançada no dia anterior . Portanto, presumo um impasse na verificação iniciada e imediatamente interrompida novamente.
Minha mitigação até agora foi desativar a nova verificação automática do MD RAID
Responder1
Você pode estar encontrando este bug:https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935. É um bug do kernel upstream com patches para corrigi-lo no Linux v5.19.
Decomente 10, você pode tentar esta solução alternativa (mude md1para md5/ md6/etc. primeiro):
echo active | sudo tee /sys/block/md1/md/array_state