quanto tempo zerar uma unidade com dd? [fechadas]

14

Quanto tempo leva para zerar o preenchimento de 1 TB (usando dd dev / zero)?

Na verdade, estou fazendo duas unidades de 500G simultaneamente, se isso importa.

— Miles Marley
fonte

3

Então, diga-nos, quanto tempo levou para dd as unidades com zeros?

— precisa

1

Meu sata WD de 1 TB (5400rpm) leva cerca de 240 minutos, mas é antigo e realocou setores. Aliás não é tão diferente do mesmo tempo que os relatórios inteligentes como o tempo para esperar um auto teste estendido para durar (255mins)

— barrymac

2

Adicionando outro ponto de dados: apenas rodamos dd if=/dev/zero of=/dev/sdX bs=8Mem duas novas unidades Seagate ST4000DM000 de 4 TB sobre portas SATA-300 simultaneamente (acho que era mais ou menos perfeitamente paralelelizável - o uso da CPU foi constante em ~ 20% no primeiro ddprocesso antes do início do segundo e, em seguida, ambos levaram ~ 20% cada). O primeiro disco terminou em 8h50min (530 min) e o segundo em 8h30min (510 min). Isso equivale a uma velocidade de gravação de ~ 130 MB / s por unidade, o que não é tão estranho, considerando a entrada monotônica. O hardware era de 2009 (CPU: C2D E8400; chipset: Intel P43 / ICH10).

— Daniel Andersson

9

Depende de muitos fatores, incluindo, entre outros:

Velocidade do disco (RPM)
Cache interno do disco
Número de pratos e se ele pode gravar em vários pratos simultaneamente
Interface de disco (SATA / SCSI, etc)
Desempenho do controlador de interface
Configuração dos inversores (por exemplo, canais separados ou mesmo canal)

Além disso, embora zerar uma unidade seja uma tarefa simples para a CPU e a RAM, ainda pode haver um efeito de:

Desempenho da CPU
RAM disponível
Velocidade da RAM
Outras tarefas sendo executadas ao mesmo tempo
Configurações de gerenciamento de energia

Supondo que um computador relativamente recente com unidades de nível médio, em um disco mínimo de inicialização do Linux executando APENAS a operação de zeragem (sem GUI, Internet, etc.) carregada inteiramente na RAM, pode demorar de 2 a 12 horas. Se eu tivesse que digitar um único número, diria que fica mais perto de três horas e meia, mas, novamente, não há informações suficientes para obter uma boa estimativa além de fazê-lo.

Se você tiver mais de 1 GB de espaço livre, tente montar a unidade e executá-la dd if=/dev/zero bs=512 count=2048 of=/tmp/tempzeroou algum outro arquivo. Se você souber mais sobre o tamanho ideal do bloco para gravar mais rapidamente em sua unidade, use-o para o valor bs (em kilobytes) e defina a contagem para o tamanho que você deseja. Em seguida, você pode usar isso para obter uma estimativa melhor sem perder dados. Apenas criará um arquivo grande que contém zeros.

— TuxRug
fonte

3

Na minha experiência em discos rígidos da última década, o bs = 1M é uma grande melhoria em relação ao bs = 512 e é bom o suficiente para usar como padrão, sem se preocupar muito em encontrar o ideal.

— crazyscot

@crazyscot sim diferença enorme lá com o bs = 1M para substituir o terrível padrão de bs = 512. Também o ddrescue (verifique como definir o tamanho do bloco), fornece uma barra de porcentagem / progresso.

— 2213 barlop

2

Eu fiz um dd com dados aleatórios em uma unidade de 750GB. Eu acho que levou cerca de 20 horas. O que realmente me chateou foi que eu tive que fazer isso quatro vezes para uma matriz RAID de quatro discos. Eu acho que o gargalo é a velocidade de gravação de suas unidades. Você está sendo esperto ao fazê-lo nas unidades em paralelo.

— Rolnik
fonte

2

Uma grande parte do seu problema de desempenho provavelmente foi o uso de números aleatórios. / dev / urandom ou qualquer outra fonte vai se esforçar muito para gerar números verdadeiramente aleatórios, diminuindo assim sua taxa de transferência. Algo como / dev / zero não terá esse problema.

— Sam Bisbee

Existe algum risco de 1 TB de zeros serem compactados em algum lugar do pipeline até o armazenamento e distorcer os resultados? Eu não quero dizer realmente comprimido no disco, mas em trânsito como uma otimização

— baiacu

2

Com uma partição de +100 GB, Acer Aspire 5750G, disco rígido externo sata, usb 2, 5400rpm:

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb2 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb2': No space left on device
12500+0 records in
12499+0 records out
104856551424 bytes (105 GB) copied, 2846.87 s, 36.8 MB/s

e

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb1 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb1': No space left on device
6579+0 records in
6578+0 records out
55183409152 bytes (55 GB) copied, 1497.23 s, 36.9 MB/s

— hsmit
fonte

1

Eu estou supondo, mas meu palpite é que isso dependeria do controlador da unidade, do controlador na placa-mãe e do que mais está absorvendo a CPU / IO.

Meu palpite, na ordem das horas ou horas. Os dias parecem longos. Dependendo de como a sua máquina estiver configurada, a execução das duas tarefas ao mesmo tempo pode realmente tornar as coisas mais lentas se você criar contenção para o controlador da unidade. Mesmo que você esteja digitando zeros, nada em sua unidade sabe disso e precisa escrever cada byte.

— Rich Homolka
fonte

1

Se você estiver apenas apagando as unidades, uma ótima ferramenta a ser usada para taxa de transferência paralela é o DBAN no modo de exclusão simples. Está disponível como ISO e basicamente executa o dd if=/dev/zerocomando para você nas unidades selecionadas.

— wajeemba
fonte

0

Deve levar de 2 a 5 horas. Seu gargalo é o disco, não a RAM, a CPU, os cabos ou a configuração do controlador. A menos que você tenha um computador muito antigo, como um Pentium original, sua CPU e memória são muito mais rápidas que a velocidade do eixo do disco rígido, assim como os cabos SATA. O cache nem entra em jogo porque você está zerando a unidade (a menos que você tenha 1 TB de cache).

— Jordânia
fonte