como usar o dd para preencher a unidade com 1s

Question

Preencher um disco com / dev / urandom parece ser muito lento, então criei um arquivo cheio de FF:

dd if=/dev/zero ibs=1k count=1000 | tr "
dd if=ff.bin of=/dev/sdb count=10000
0" "7" >ff.bin

Eu gostaria de preencher a unidade com cópias deste arquivo, mas o seguinte comando só grava uma vez:

dd if=/dev/zero ibs=1k count=1000 | tr "
dd if=ff.bin of=/dev/sdb count=10000
0" "7" >ff.bin

Como faço para preencher a unidade com cópias do arquivo, ou há uma maneira mais rápida de preencher a unidade com 1s?

    

Answer 1

Faça simplesmente:

tr '
tr '%pre%' '7' < /dev/zero > /dev/sdb
' '7' < /dev/zero > /dev/sdb

Será anulado com um erro quando a unidade estiver cheia.

Usar dd não faz sentido aqui. Você usa dd para garantir que leituras e gravações sejam feitas de um tamanho específico. Não há razão para fazer isso aqui. tr fará leituras / gravações de 4 ou 8 kiB, o que deve ser bom o suficiente.

    

Answer 2

Para uma alternativa mais rápida de /dev/urandom , há shred -v -n 1 (se o pseudo-aleatório for OK) ou usando cryptsetup com chave aleatória e zerando isso (para zeros criptografados). Mesmo sem a aceleração AES, ele bate facilmente em /dev/urandom de velocidade.

Não sabe com que rapidez o tr é, senão você poderia apenas dd if= | tr | dd of= .

Usar um arquivo como fonte padrão pode ser feito assim:

(while [ 1 ]; do cat file; done) | dd of=...

Embora o arquivo deva ser razoavelmente grande para que seja remotamente eficiente.

Se o count= for importante para você, adicione iflag=fullblock ao comando dd . Leituras parciais são possíveis, o que resultaria em blocos parciais a serem contados como blocos completos. Isso é especialmente quando se usa blocos maiores (como bs=1M ), o que você deve fazer se quiser velocidade.

    

Answer 3

Esta é uma maneira muito rápida e eficiente de gravar strings de 64 kB de 0xFF várias vezes, usando awk , consumindo < 8% da CPU e limitada apenas pela velocidade da unidade em que você está gravando.

Eu tentei usar tr como foi sugerido aqui e achei que era muito lento e consome muita CPU traduzindo cada byte. Meu método funciona em blocos de 64 kB e é pelo menos 3,5x mais rápido do que o tr baseado em caractere único (26 MB / s versus 7 MB / s no antigo PATA hw - terminando em 52 minutos em silêncio versus 3+ horas com alto ventilador de refrigeração revs ...). Eu gosto quando as pessoas ignoram o conhecimento básico da ciência da computação sem sequer testar sua opinião primeiro.

Eu recomendo criar o script a seguir usando printf do shell em vez de tentar escrevê-lo em vi , já que a maioria dos CD-ROMs de inicialização não fornecerá espaço tmp suficiente para o log do buffer copiar e colar 65,536 vezes ...

1) Componha o script

$ printf "echo | awk '{\n\twhile (1) {\n\t\tprintf(\"%%s\", \"" >/tmp/writeones.sh
$ for i in 'seq 1 65536'; do printf '7' >>/tmp/writeones.sh; done
$ printf "\");\n}\n}'\n" >>/tmp/writeones.sh

2) Teste o script:

$ sh /tmp/writeones.sh | od -Ax -tx1
000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
Ctrl+C

3) Execute o script e o pipe na sua unidade com dd (verifique se você tem a unidade certa !!!):

# sh /tmp/writeones.sh | dd of=/dev/ada0 bs=65536 &

Por que escolhi 64 kB? 1. Limitação da lista de argumentos do AWK, e 2. para o meu hardware, isso alcança a melhor velocidade para mim. Eu também tentei escrever isso em shell usando o printf e descobri que ele era 40% mais lento e consumia 80% da CPU por causa de todos os garfos.

    

Answer 4

Para testar a velocidade do SSD, escrevi um pequeno programa em Perl para escrever "zeros", "uns" ou alfanuméricos em um dispositivo de bloco dado na linha de comando. Ele não invoca o dd golem, apenas faz gravações diretas e sincronizações. Pode ser de ajuda aqui:

link

Basta executá-lo como

wildly_fill_block_device.pl --dev=sdX1 --fillpat 1 --chunksize=1024P --sync

E ele irá escrever 0xFFs para / dev / sdX1 (sem buffer, usando o syswrite () do Perl) em pedaços de (neste caso) "1024 blocos físicos" enquanto sincroniza os dados para o disco após cada gravação usando fdatasync () . No meu SSD, isso é executado em ~ 70 MiB / s.

Ele perguntará se você está CERTO antes de prosseguir para a partição ou o disco.