update: Ao analisar lsusb e dmesg , confirmou que a unidade caiu do barramento USB. Então o mkfs parou. kill -9 pode pará-lo e permitir que o array mdraid seja interrompido, ou uma reinicialização pode ser necessária. Se você tiver que reinicializar, esteja ciente de que o sistema pode não ser reinicializado de maneira limpa - então seria melhor sincronizar e desmontar / remontar somente leitura qualquer outro sistema de arquivos gravável, pois você pode ter que pressionar reset.
Dependendo do sistema de arquivos e das opções, o mkfs pode levar muito tempo (e o ext3 é o que faz). É seguro finalizar, mas é claro que você terá que executar o mkfs novamente. O que, se estiver realmente progredindo, significa que você terá que esperar novamente (e começará do início).
ext4 é muito mais rápido para o mkfs, especialmente com lazy_itable_init (que é o padrão). Se possível, mude.
Lembre-se que com um sistema de arquivos ext2 / 3/4, x% do disco é consumido para tabelas de inode. Sem lazy_itable_init, eles estão todos sendo escritos agora. São muitos dados para escrever (aproximadamente 1,6% do disco com configurações padrão) e não se espalham por todo o disco.
Isso também dá outra maneira de reduzir o tempo: escreva menos inodes. Mas, claro, se você for muito baixo, vai acabar.
Se você quiser verificar se está realmente progredindo, confirme se a E / S está acontecendo. Alguns discos têm uma luz indicadora, ou você pode dizer com freqüência (com discos magnéticos) segurando seu ouvido perto e ouvindo.
Como alternativa, se você tiver iostat disponível, iostat -kx 10 mostrará as primeiras estatísticas de E / S desde a inicialização, depois todas as estatísticas de 10 em relação às 10 anteriores. Você pode procurar o número de gravações sendo feitas e a utilização do disco.