Quanto tempo demora o mkfs -c?

Question

Atualmente estou executando um

sudo mkfs.msdos -c -F 32 /dev/sdg1

Quanto tempo levaria aproximadamente? Este é um disco USB 2.0 de 250GB. O limite inferior é, naturalmente, 2 * 250GB / 480 Mbit/s ~ 8400s (ele deve escrever e ler todo o disco), mas temo que possa ser mais lento do que isso.

Alguém tem uma experiência em primeira mão?

Só para tornar essa mensagem mais fácil de ler, deixe-me digitar rápido e devagar: quão rápido será? quão lento?

    

Answer 1

Parece que funcionou para você, mas para um registro ...

A verificação de blocos pode levar um longo tempo incrivelmente se você tiver blocos ruins reais que causam erros de E / S; dependendo do driver, o erro e o que ele usa para recuperar. Os SSDs devem ser mais rápidos e presumivelmente menos propensos a erros, mas os erros ainda podem torná-lo muitas vezes o melhor caso cenário.

Eu sugeriria usar dmesg para ver se está tendo problemas se parecer excessivamente lento.

BTW, por que você acha que deve gravar em todo o disco? Não vejo na página do manual mkfs.vfat (1) onde ele faz um teste destrutivo, o programa badblocks (1) faz um teste somente leitura por padrão .

E FWIW, eu tive mkfs -c levando mais de 24 horas (IIRC) em um disco SCSI que era ~ 4GB.

    

Answer 2

Eu executei badblocks /dev/sdg1 em um HDD de 1TB via USB 2.0, que é, de acordo com a página do manual, o que um comando mkfs.* -c faria. O tamanho do bloco de teste padrão é de 1 KiB e executa um teste somente leitura por padrão.

Após 24 horas abortei: ele testou apenas 120GB e encontrou mais de 10000 blocos defeituosos. Como @nvram apontou, pode ser muito lento quando você realmente tem blocos ruins.

Portanto, para o seu disco rígido, pode demorar mais de 2 dias.

    

Answer 3

Não levou muito mais que o limite inferior. Infelizmente eu não parei de assistir, mas mais ou menos isso foi isso.

    

Answer 4

Obrigado pelas dicas! Gostaria de contribuir com minhas experiências para solucionar problemas do Ubuntu não inicializável do meu amigo. Eu inicializei o PC com o Xubuntu em mídia USB. Depois de usar o comando e2fsck , a partição do disco rígido pode ser montada e os arquivos podem ser recuperados do disco rígido (e meu amigo ficou feliz :).

Mensagens de erro de falha no disco rígido podem ser vistas no buffer de anel do kernel (e podem ser impressas com o comando dmesg ):

[78748.550250] ata1.00: status: { DRDY ERR }
[78748.550253] ata1.00: error: { UNC }
[78748.572323] ata1.00: configured for UDMA/100
[78748.572341] ata1: EH complete
[78753.326771] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[78753.326777] ata1.00: BMDMA stat 0x25
[78753.326782] ata1.00: failed command: READ DMA
[78753.326790] ata1.00: cmd c8/00:08:48:0b:44/00:00:00:00:00/e4 tag 0 dma 4096 in
[78753.326792]          res 51/40:08:48:0b:44/40:00:04:00:00/e4 Emask 0x9 (media error)

Quando tentei instalar o Xubuntu no PC, a instalação parou devido a esses erros de mídia. Eu usei o Gparted para particionar o disco rígido e o comando mke2fs para tornar o sistema de arquivos ext4 excluindo blocos ruins.

ubuntu@ubuntu:~$ sudo mke2fs -c -t ext4 /dev/sda1
...
...
...
Checking for bad blocks (read-only test):  18.07% done, 2:54:19 elapsed
 18.20% done, 8:14:58 elapsed
 18.20% done, 8:22:01 elapsed
^[[B20% done, 8:35:08 elapsed

A verificação de bloqueio é tão lenta que achei que a execução estava comprometida. Quase parou em torno de 18% e parecia que nunca chegará ao fim. Mas o dmesg mostrou que o bloco é escalonado e que a verificação do bloco está em andamento. Se os blocos estiverem ok, a checagem de blocos é mais rápida e toda a execução levou cerca de 24 horas. O tamanho do disco rígido é de 40 GB.