Eu tinha um array RAID5 funcional composto por 6 discos de 4 TB. Smartd relatou que um dos discos começou a falhar. Decidi fazer várias coisas em uma operação: 1) remover o disco com falha 2) adicionar um novo para substituí-lo 3) adicionar mais alguns discos ao array e aumentá-lo
Como eu só tinha discos menores para (3), usei o LVM para juntar discos menores em volumes maiores que 4 TB
Aqui está a sequência do que executei:
1) vgcreate vg_sdi_sdj /dev/sdi1 /dev/sdj1
2) vgcreate vg_sdj_sdl /dev/sdk1 /dev/sdl1
3) lvcreate -l 100%FREE -n all vg_sdi_sdj
4) lvcreate -l 100%FREE -n all vg_sdk_sdl
5) mdadm --manage /dev/md1 --add /dev/sdg1
6) mdadm --manage /dev/md1 --add /dev/vg_sdi_sdj/all
7) mdadm --manage /dev/md1 --add /dev/vg_sdk_sdl/all
8) mdadm --manage /dev/md1 --fail /dev/sdc1
9) mdadm --grow --raid-devices=8 --backup-file=/home/andrei/grow_md1.bak /dev/md1
No começo tudo estava indo quase bem. Array começou a reconstruir. A única estranheza foi que o arquivo de backup não foi criado. eu estava correndo
watch -n 1 mdadm --detail /dev/md1
nmon
em segundo plano para ficar de olho nas coisas. Enquanto a reconstrução estava acontecendo, pude acessar o array.
No entanto, após 9% do processo, todas as E/S no array foram interrompidas, exceto 100% de leituras em /dev/sdb e /dev/sdb1. Depois que matei watch -n 1 mdadm, isso também parou.
Aqui está a saída recente de mdadm --detail:
/dev/md1: Version : 1.2 Creation Time : Sun Jan 8 22:16:01 2017 Raid Level : raid5 Array Size : 19534430720 (18629.49 GiB 20003.26 GB) Used Dev Size : 3906886144 (3725.90 GiB 4000.65 GB) Raid Devices : 8 Total Devices : 8 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Jan 15 21:38:17 2017 State : clean, degraded, reshaping Active Devices : 7 Working Devices : 8 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Reshape Status : 9% complete Delta Devices : 2, (6->8) Name : server:1 (local to host server) UUID : bec66f95:2975e7ae:8f8ba15c:8eb3a33f Events : 79504 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 9 252 0 1 spare rebuilding /dev/dm-0 2 8 49 2 active sync /dev/sdd1 3 8 145 3 active sync /dev/sdj1 4 8 161 4 active sync /dev/sdk1 6 8 177 5 active sync /dev/sdl1 8 252 1 6 active sync /dev/dm-1 7 8 129 7 active sync /dev/sdi1
Não consegui fazer nenhuma E/S no array. A execução do htop mostrou um núcleo da CPU vinculado a 100% realizando operações de E/S.
Eu reiniciei a máquina. Array não foi remontado. Eu o remontei manualmente executando:
mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
(após a reinicialização, os discos mudaram de nome). No entanto, o lvm encontrou volumes e grupos corretamente e os trouxe.
Sem força não jogaria bola. Ele foi montado e mostrou o relatório --detail citado acima.
No entanto, ele ainda não permitiria nenhuma E/S, então o comando de montagem congelou (eu tenho um único disco LVM e um sistema de arquivos ext4 dentro). htop também mostrou um núcleo de CPU vinculado a E/S.
No entanto, nenhum dos LEDs de atividade do disco está aceso.
No momento, estou preso a um array não funcional que contém uma boa quantidade de dados. Idealmente, gostaria de recuperar os dados.
Talvez usar volumes lógicos LVM como "discos" mdadm tenha sido um erro. Embora eu não tenha encontrado nenhuma informação indicando que não funcionaria.
Eu realmente apreciaria qualquer conselho e dicas sobre como recuperar meu array.
Uma análise mais detalhada de journalctl -xe revelou o seguinte:
Jan 15 22:41:15 server sudo[1612]: andrei : TTY=tty1 ; PWD=/home/andrei ; USER=root ; COMMAND=/sbin/mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
Jan 15 22:41:15 server sudo[1612]: pam_unix(sudo:session): session opened for user root by andrei(uid=0)
Jan 15 22:41:15 server kernel: md: md1 stopped.
Jan 15 22:41:15 server kernel: md: bind<dm-1>
Jan 15 22:41:15 server kernel: md: bind<sdd1>
Jan 15 22:41:15 server kernel: md: bind<sdg1>
Jan 15 22:41:15 server kernel: md: bind<sdh1>
Jan 15 22:41:15 server kernel: md: bind<sdf1>
Jan 15 22:41:15 server kernel: md: bind<dm-0>
Jan 15 22:41:15 server kernel: md: bind<sde1>
Jan 15 22:41:15 server kernel: md: bind<sdb1>
Jan 15 22:41:15 server mdadm[879]: NewArray event detected on md device /dev/md1
Jan 15 22:41:15 server mdadm[879]: DegradedArray event detected on md device /dev/md1
Jan 15 22:41:15 server kernel: md/raid:md1: reshape will continue
Jan 15 22:41:15 server kernel: md/raid:md1: device sdb1 operational as raid disk 0
Jan 15 22:41:15 server kernel: md/raid:md1: device sde1 operational as raid disk 7
Jan 15 22:41:15 server kernel: md/raid:md1: device dm-0 operational as raid disk 6
Jan 15 22:41:15 server kernel: md/raid:md1: device sdf1 operational as raid disk 5
Jan 15 22:41:15 server kernel: md/raid:md1: device sdh1 operational as raid disk 4
Jan 15 22:41:15 server kernel: md/raid:md1: device sdg1 operational as raid disk 3
Jan 15 22:41:15 server kernel: md/raid:md1: device sdd1 operational as raid disk 2
Jan 15 22:41:15 server kernel: md/raid:md1: allocated 8606kB
Jan 15 22:41:15 server kernel: md/raid:md1: raid level 5 active with 7 out of 8 devices, algorithm 2
Jan 15 22:41:15 server kernel: RAID conf printout:
Jan 15 22:41:15 server kernel: --- level:5 rd:8 wd:7
Jan 15 22:41:15 server kernel: disk 0, o:1, dev:sdb1
Jan 15 22:41:15 server kernel: disk 1, o:1, dev:dm-1
Jan 15 22:41:15 server kernel: disk 2, o:1, dev:sdd1
Jan 15 22:41:15 server kernel: disk 3, o:1, dev:sdg1
Jan 15 22:41:15 server kernel: disk 4, o:1, dev:sdh1
Jan 15 22:41:15 server kernel: disk 5, o:1, dev:sdf1
Jan 15 22:41:15 server kernel: disk 6, o:1, dev:dm-0
Jan 15 22:41:15 server kernel: disk 7, o:1, dev:sde1
Jan 15 22:41:15 server kernel: created bitmap (30 pages) for device md1
Jan 15 22:41:15 server kernel: md1: bitmap initialized from disk: read 2 pages, set 7 of 59615 bits
Jan 15 22:41:16 server kernel: md1: detected capacity change from 0 to 20003257057280
Jan 15 22:41:16 server kernel: md: reshape of RAID array md1
Jan 15 22:41:16 server kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Jan 15 22:41:16 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape.
Jan 15 22:41:16 server kernel: md: using 128k window, over a total of 3906886144k.
Jan 15 22:41:16 server mdadm[879]: RebuildStarted event detected on md device /dev/md1
Jan 15 22:41:16 server sudo[1612]: pam_unix(sudo:session): session closed for user root
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589312 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589320 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589328 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589336 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589344 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589352 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589360 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589368 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589376 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759582288 on sdf1)
...
Jan 15 22:43:36 server kernel: INFO: task md1_reshape:1637 blocked for more than 120 seconds.
Jan 15 22:43:36 server kernel: Not tainted 4.4.0-59-generic #80-Ubuntu
Jan 15 22:43:36 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 15 22:43:36 server kernel: md1_reshape D ffff88021028bb68 0 1637 2 0x00000000
Jan 15 22:43:36 server kernel: ffff88021028bb68 ffff88021028bb80 ffffffff81e11500 ffff88020f5e8e00
Jan 15 22:43:36 server kernel: ffff88021028c000 ffff8800c6993288 ffff88021028bbe8 ffff88021028bd14
Jan 15 22:43:36 server kernel: ffff8800c6993000 ffff88021028bb80 ffffffff818343f5 ffff8802144c7000
Jan 15 22:43:36 server kernel: Call Trace:
Jan 15 22:43:36 server kernel: [<ffffffff818343f5>] schedule+0x35/0x80
Jan 15 22:43:36 server kernel: [<ffffffffc01d2fec>] reshape_request+0x7fc/0x950 [raid456]
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffffc01d346b>] sync_request+0x32b/0x3b0 [raid456]
Jan 15 22:43:36 server kernel: [<ffffffff81833d46>] ? __schedule+0x3b6/0xa30
Jan 15 22:43:36 server kernel: [<ffffffff8140c305>] ? find_next_bit+0x15/0x20
Jan 15 22:43:36 server kernel: [<ffffffff81704c5c>] ? is_mddev_idle+0x9c/0xfa
Jan 15 22:43:36 server kernel: [<ffffffff816a20fc>] md_do_sync+0x89c/0xe60
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffff8169e689>] md_thread+0x139/0x150
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffff8169e550>] ? find_pers+0x70/0x70
Jan 15 22:43:36 server kernel: [<ffffffff810a0c08>] kthread+0xd8/0xf0
Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
Jan 15 22:43:36 server kernel: [<ffffffff8183888f>] ret_from_fork+0x3f/0x70
Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
Responder1
Usar o LVM para isso foi realmente um erro. Além de criar uma pilha de armazenamento desnecessária e complicada para qualquer pessoa que não seja seu criador, os arrays MD são construídos antes dos arrays LVM, exigindo que você invoque manualmente a varredura MD em seus LVs que atuam como membros MD.
Além disso, evite o uso de nomes de dispositivos do kernel em configurações persistentes (como sda, sdb, etc). Isto é especialmente relevante ao nomear um grupo de volumes, pois os VGs abstraem o armazenamento subjacente e podem ser movidos livremente entre os PVs. Os nomes dos dispositivos do kernel também não são considerados permanentes e podem mudar a qualquer momento por vários motivos. Isso não é um problema para os PVs LVM (já que eles fazem parte de uma varredura de disco por atacado e detectam praticamente qualquer coisa), mas seu nome VG rapidamente não refletirá a realidade na situação que você criou.
Eu recomendaria que você tentasse remover normalmente o LV do seu array MD e trazê-lo de volta a um estado degradado (mas são). Esteja ciente de que o MD no topo do LVM não é algo com que as pessoas se preocupam ao destruir bugs. Você está em um território desconhecido e as coisas que você espera que funcionem podem falhar sem motivo aparente.
Se esses dados forem críticos e não tiverem backup, você deve recorrer a alguém no local que conheça LVM e MD muito bem. Presumo que você não tenha isso, já que está perguntando aqui, então vamos conversar se precisar. Atualizarei isso com quaisquer detalhes interessantes se você tiver que seguir esse caminho. Por enquanto, tente recuar substituindo a bagunça do LVM por um disco simples e antigo para um membro.