fsck está em execução há mais de 30 dias em 30TB de partição ext4, não é possível montar

6

Dada uma partição de discos de 30 TB no hw raid5. O LVM está no topo e o sistema de arquivos é o ext4. (É 99,9% cheio de dados.) Eu queria adicionar mais 20 TB e redimensionar a partição e o sistema de arquivos. Antes de redimensionar, insistia em executar o FSCK primeiro. Ele está sendo executado há mais de uma semana, cancelei, mas não consegui montar a partição. O FSCK foi requerido primeiro. Então eu comecei de novo.

fsck.ext4 -v -C 0 /dev/vgname/lvname
e2fsck 1.44.3 (10-July-2018)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

Resize inode not valid.  Recreate<y>? yes

E desde que 31 dias se passaram e ele ainda está em exibição, ocupando 1 núcleo de CPU 100%.

Ao olhar para ele com strace , é isso que eu vejo:

strace -p 3174
strace: Process 3174 attached
strace: [ Process PID=3174 runs in x32 mode. ]
strace: [ Process PID=3174 runs in 64 bit mode. ]
pread64(4, "502405=$5415415l?6?U6?615:557"..., 4096, 2447145635840) = 4096
mremap(0x7fa5e3565000, 208764928, 208769024, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "
fsck.ext4 -v -C 0 /dev/vgname/lvname
e2fsck 1.44.3 (10-July-2018)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

Resize inode not valid.  Recreate<y>? yes
5
strace -p 3174
strace: Process 3174 attached
strace: [ Process PID=3174 runs in x32 mode. ]
strace: [ Process PID=3174 runs in 64 bit mode. ]
pread64(4, "502405=$5415415l?6?U6?615:557"..., 4096, 2447145635840) = 4096
mremap(0x7fa5e3565000, 208764928, 208769024, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "%pre%5%pre%167q77Q47117H57367177527J67"..., 4096, 1724118507520) = 4096
pread64(4, "x71p7_b77W7[73N76[7&h7QS73O7sT7"..., 4096, 3443764559872) = 4096
pread64(4, "73175573%pre%7676%pre%037?%pre%2575%pre%|47D"..., 4096, 6956990242816) = 4096
pread64(4, "%pre%013%pre%)3%pre%=3%pre%6/3%pre%6/3%pre%673%pre%0*3%pre%693"..., 4096, 8609803698176) = 4096
pread64(4, "o\f757=70622R3472343Z6LI"..., 4096, 1755810463744) = 4096
mremap(0x7fa5e3565000, 208769024, 208773120, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "%pre%\%pre%727737?07647Ht7W75G7G7}[7"..., 4096, 14672424988672) = 4096
mremap(0x7fa5e3565000, 208773120, 208777216, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "52)#mN4F01+.264067037P2"..., 4096, 16981972766720) = 4096
mremap(0x7fa5e3565000, 208777216, 208781312, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "M%pre%5N%pre%KO%pre%P%pre%1P%pre%)Q%pre%6Q%pre%4R%pre%SS%pre%\tT%pre%1T%pre%"..., 4096, 833004105728) = 4096
167q77Q47117H57367177527J67"..., 4096, 1724118507520) = 4096 pread64(4, "x71p7_b77W7[73N76[7&h7QS73O7sT7"..., 4096, 3443764559872) = 4096 pread64(4, "73175573%pre%7676%pre%037?%pre%2575%pre%|47D"..., 4096, 6956990242816) = 4096 pread64(4, "%pre%013%pre%)3%pre%=3%pre%6/3%pre%6/3%pre%673%pre%0*3%pre%693"..., 4096, 8609803698176) = 4096 pread64(4, "o\f757=70622R3472343Z6LI"..., 4096, 1755810463744) = 4096 mremap(0x7fa5e3565000, 208769024, 208773120, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "%pre%\%pre%727737?07647Ht7W75G7G7}[7"..., 4096, 14672424988672) = 4096 mremap(0x7fa5e3565000, 208773120, 208777216, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "52)#mN4F01+.264067037P2"..., 4096, 16981972766720) = 4096 mremap(0x7fa5e3565000, 208777216, 208781312, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "M%pre%5N%pre%KO%pre%P%pre%1P%pre%)Q%pre%6Q%pre%4R%pre%SS%pre%\tT%pre%1T%pre%"..., 4096, 833004105728) = 4096

Uma nova linha é produzida a cada 30-60 segundos, muito raramente. Alguém pode me dar uma pista do que está acontecendo e devo esperar ou o que deve ser feito para poder acessar os dados novamente?

    
por G Grosschmid 22.09.2018 / 10:08

2 respostas

0

Por favor, execute os seguintes passos,

Desmonte o disco primeiro,

umount / dev / disk

O Linux mantém várias cópias redundantes do superbloco em cada sistema de arquivos. Podemos recuperar dados usando cópias redundantes de metadados de superblocos.

dumpe2fs / dev / disk | grep superblock

Ele mostrará superblocos alternativos que podemos usar.

fsck -y -b blockid / dev / disco

Repita o passo para todos os super blocos danificados. ou seja, substituir os superblocos por superblocos de backup.

monte o disco e pode usar novamente

    
por 26.09.2018 / 12:06
0

obrigada a todos por sugestões. O disco foi desmontado antes de executar o fsck. Depois que eu recebi a sugestão de resposta do antony_sebastian entrei no servidor para tentar isso, retomei o comando screen e o fsck estava aguardando a entrada. Surpreendentemente, após 33 dias de verificação, ele terminou o processamento do disco de 30 TB. Respondendo "sim" a todos os problemas corrigíveis, os dados estavam de volta, embora tudo tenha sido movido para "Perdido + encontrado" e os nomes das pastas de árvores dos diretórios raiz tenham sido perdidos. Além disso, os dados estavam intactos e bem.

Obrigado pelas sugestões e ajuda, tudo!

    
por 20.10.2018 / 08:49