Por que o dd é tão lento com um bs de 100M [fechado]

Question

Eu apenas tentei substituir um ssd rápido usando dd. Usando a imagem de inicialização do ubuntu eu digitei:

dd if=/dev/zero of=/dev/sda bs=100M
error writing '/dev/sda': No space left on device
blah blah
256 GB copied, 1195.81 s 214 MB/s

Isso não é muito lento? E onde está o gargalo? E quanto à escolha do tamanho do bloco?

    

Answer 1

Blocos perfeitos para dd estão em torno de 64k - 256k , os humanos geralmente preferem 1M .

Um benchmark sem E / S real:

$ for bs in 512 4k 16k 64k 128k 256k 512k 1M 4M 16M 64M 128M 256M 512M
> do
>     echo ---- $bs: ----
>     dd bs=$bs if=/dev/zero of=/dev/null iflag=count_bytes count=10000M
> done
---- 512: ----
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 4.2422 s, 2.5 GB/s
---- 4k: ----
2560000+0 records in
2560000+0 records out
10485760000 bytes (10 GB) copied, 0.843686 s, 12.4 GB/s
---- 16k: ----
640000+0 records in
640000+0 records out
10485760000 bytes (10 GB) copied, 0.533373 s, 19.7 GB/s
---- 64k: ----
160000+0 records in
160000+0 records out
10485760000 bytes (10 GB) copied, 0.480879 s, 21.8 GB/s
---- 128k: ----
80000+0 records in
80000+0 records out
10485760000 bytes (10 GB) copied, 0.464556 s, 22.6 GB/s
---- 256k: ----
40000+0 records in
40000+0 records out
10485760000 bytes (10 GB) copied, 0.48516 s, 21.6 GB/s
---- 512k: ----
20000+0 records in
20000+0 records out
10485760000 bytes (10 GB) copied, 0.495087 s, 21.2 GB/s
---- 1M: ----
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 0.494201 s, 21.2 GB/s
---- 4M: ----
2500+0 records in
2500+0 records out
10485760000 bytes (10 GB) copied, 0.496309 s, 21.1 GB/s
---- 16M: ----
625+0 records in
625+0 records out
10485760000 bytes (10 GB) copied, 0.972703 s, 10.8 GB/s
---- 64M: ----
156+1 records in
156+1 records out
10485760000 bytes (10 GB) copied, 1.0409 s, 10.1 GB/s
---- 128M: ----
78+1 records in
78+1 records out
10485760000 bytes (10 GB) copied, 1.04533 s, 10.0 GB/s
---- 256M: ----
39+1 records in
39+1 records out
10485760000 bytes (10 GB) copied, 1.04685 s, 10.0 GB/s
---- 512M: ----
19+1 records in
19+1 records out
10485760000 bytes (10 GB) copied, 1.0436 s, 10.0 GB/s

• O 512 bytes padrão é lento como o inferno (dois syscalls por 512 bytes são demais para a CPU)
• 4k é consideravelmente melhor que 512
• 16k é consideravelmente melhor que 4k
• 64k - 256k é quase tão bom quanto
• 512k - 4M ligeiramente mais lento
• 16M - 512M reduz a velocidade pela metade, pior que 4k .

Meu palpite é que, começando com um determinado tamanho, você começa a perder velocidade devido à falta de simultaneidade. dd é um processo único; A concorrência é largamente fornecida pelo kernel (readahead, cache de write, ...). Se tiver que ler 100M antes de poder escrever 100M, haverá momentos em que um dispositivo ficará ocioso, aguardando que o outro termine de ler ou escrever. Blocos muito pequenos e você sofre de sobrecarga syscall, mas isso desaparece completamente com 64k ou mais.

Blocos de 100M ou maiores podem ajudar na cópia de e para o mesmo dispositivo. Pelo menos para discos rígidos, isso deve reduzir o tempo perdido na busca, pois não pode estar em dois lugares simultaneamente.

Por que você está sobrescrevendo seu SSD assim em primeiro lugar? Normalmente, você tenta evitar gravações desnecessárias em SSDs; se considerar todo o seu espaço usado, provavelmente também perderá parte de seu desempenho até que você o liberte novamente.

Você poderia usar este comando para TRIM / descartar seu SSD inteiro:

blkdiscard /dev/sda

Se o seu SSD tiver zeros de leitura determinísticos após TRIM (uma propriedade que você pode verificar com hdparm -I ) ele parecerá cheio de zeros, mas o SSD realmente considera todos os blocos como gratuitos, o que deve lhe dar o melhor desempenho.

A desvantagem do TRIM é que você perde todas as chances de recuperação de dados se o arquivo excluído já tiver sido descartado ...