resize2fs parece preso no passo 3 (varrendo a tabela de inode) - o que fazer?

Question

Eu tenho uma máquina rodando o Arch Linux (2010, eu acredito) com uma matriz RAID-5 de 6TB conectada a um Highpoint RocketRaid 2320. Eu tenho tido problemas com os drivers do controlador RAID e os kernels mais recentes do Linux graças ao driver não sendo de código aberto e, como resultado, estou migrando o sistema para o Windows Server.

O problema é que o disco de 6 TB originalmente era composto apenas por uma partição ext4. Reduzi a partição o máximo que pude e adicionei uma partição NTFS no espaço vazio para poder começar a mover os arquivos. Isso foi bem. O problema é que agora eu preciso reduzir a partição ext4 novamente , mover arquivos, encolher novamente, etc. A segunda execução através de resize2fs está demorando mais do que a primeira passagem. Parece estar ficando preso no passo 3:

[root@nar-shaddaa rc.d]# resize2fs -p /dev/sdb3 863000000
resize2fs 1.41.14 (22-Dec-2010)
Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks.
Begin pass 2 (max = 29815167)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 36670)
Scanning inode table          XXXXXXXXXXX-----------------------------

Tem sido assim, sugando 100% de um núcleo por mais de 19 horas agora:

[root@nar-shaddaa rc.d]# ps aux | grep resize2fs
root     16277 94.1 19.8 627096 613940 pts/1   R+   Jun15 1184:37 resize2fs -p /dev/sdb3 863000000

Eu originalmente tinha percorrido resize2fs -P /dev/sdb3 para obter o tamanho mínimo da partição, mas para ser seguro, arredondado para o próximo milionésimo bloco (daí o mesmo para 863 milhões). Antes de iniciar o resize2fs, o e2fsck reportou o sistema de arquivos como limpo:

[root@nar-shaddaa rc.d]# e2fsck -yv /dev/sdb3
e2fsck 1.41.14 (22-Dec-2010)
x-files: clean, 286672/300400640 files, 867525660/1201576187 blocks

Estou preocupado porque isso tem acontecido por muito mais do que o primeiro redimensionamento (que foi de pouco menos de uma hora), e parece que não estou recebendo nenhum tipo de atualização Resize2fs ainda está claramente sugando ciclos de CPU. Eu espero mais (e em caso afirmativo, quanto tempo)? Ou eu cancelo e uso uma ferramenta diferente para redimensionar a partição?

    

Answer 1

Eu finalmente descobri o que era. Depois de cancelar o redimensionamento original (apenas um simples ctrl + C), eu corri e2fsck -f -y /dev/sdb3 para corrigir qualquer problema que eu fizesse. Consegui montar a partição ainda abaixo do tamanho original, por isso não foram perdidos dados. Em seguida, executei resize2fs com o sinalizador de depuração ( resize2fs -d 14 <xxx> ) e observei que ele estava preso em um loop constante tentando realocar um pedaço de inodes.

Eu finalmente consegui que funcionasse usando uma versão mais antiga do e2fsprogs. Coloquei o Ubuntu 9.10 (Karmic Koala) em um pen drive, inicializei nele, instalei os drivers rr232x de código aberto para poder manipular o array e executei a versão mais antiga do e2fsprogs (resize2fs 1.41.9 (22-Ago-2009) , para ser exato).

Eu tinha tentado originalmente o resize2fs -p /dev/sdb3 863000000 e ele me disse que precisava de ~ 26 milhões de blocos. Então peguei o tamanho do alvo, adicionei isso a ele e fiz resize2fs -p /dev/sdb3 1000000000 . 10 minutos depois, sou recebido com a mensagem:

/dev/sdb3 is now at 1000000000 blocks

Agora eu acho que a última pergunta é por que a nova versão do e2fsprogs não poderia / não me dizer que eu estava pedindo um tamanho muito pequeno (e por que ele ofereceu um tamanho tão pequeno em primeiro lugar)?