Configuração: Unidades de 12 TB 1 TB em um RAID6 (MDADM) crypt-setup rodando ontop do MDADM LVM rodando nas unidades crypted EXT4 no LVM
Antecedentes: Eu adicionei uma nova unidade ao RAID (aumentando de 11 para 12 unidades), e 'borbulhei' através das camadas (MDADM, etc ...) para redimensionar a partição ext4. Esta máquina é usada como um repositório centralizado para fotografia e como um servidor de backup (para máquinas Windows e Mac), então reduzi-lo para adicionar a unidade e aguardar o redimensionamento e tudo não era realmente uma opção. Então comecei a operação de redimensionamento há vários dias. O HTOP está relatando a operação resize2fs como sendo executada por 81h agora. O DMESG e o syslog são claros e as unidades ainda são acessíveis. O comando de redimensionamento relata que começou um redimensionamento online da partição, portanto, o processo está em execução e está sendo gravado em 100% de um dos meus núcleos.
Pergunta: É normal que a operação demore tanto ou algo deu errado? Onde eu começaria a procurar sinais de problemas?
Se você executasse resize2fs com a opção -p , ele imprimia relatórios de progresso regulares. No entanto, como você não o fez, parece não haver nenhuma maneira de obter essa informação enquanto ela está em execução.
Esta questão relacionada parece indicar que é bastante normal que resize2fs seja executado por um tempo muito longo.
Eu não sei se resize2fs suporta, mas você pode tentar enviar um sinal USR1
killall -USR1 resize2fs
O que eu estou querendo saber: quanto tempo demorou sua atualização do mdadm? Isso deve ter levado muito mais tempo do que o ext-redimensionar do meu ponto de vista.
Editar: Pode ser que, em segundo plano, o seu RAID ainda esteja migrado (o md ainda está muito ativo) e que o processo de redimensionamento foi bloqueado / desacelerado por causa disso?
Tags ext4 filesystems ubuntu