Reiniciando um DD de um disco inteiro

10

Estou substituindo meu disco rígido por dados aleatórios usando o bom e velho dd:

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=512

É uma matriz de 2 TB e meu MacBook (executando Linux, ok?) Só pode gravar dados em torno de 3,7 MB / s, o que é bastante patético, já que eu vi minha área de trabalho em casa fazer 20 MB / s. Quando vou para casa hoje à noite, gostaria de parar a ddcorrida aqui, levá-la para casa e ver que tipo de progresso pode ser feito da noite para o dia com uma máquina mais poderosa.

Eu tenho monitorado o progresso usando um loop simples:

while true; do kill -USR1 $PID ; sleep 10 ; done

A saída é assim:

464938971+7 records in
464938971+7 records out
238048755782 bytes (238 GB) copied, 64559.6 s, 3.7 MB/s

Se eu retomasse o ddpasse em casa, como o reiniciaria? Estou ciente do seekparâmetro, mas para o que aponto, o número do registro ou a contagem de bytes?

dd Naftuli Kay
fonte
1
Eu uso o número do registro? Isso é igual ao bloco escrito?
Naftuli Kay
2
O número de blocos = total de bytes / tamanho do bloco, em teoria, deveria ser 238048755782/512 = 464938976, mas você tem alguns registros parciais lá, então eu subtrairia alguns blocos do número apenas para garantir a segurança, por exemploseek=464938960
don_crissti

Respostas:

8

Como o @don_crissti já comentou, use seek=para continuar.

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=512 seek=464938971

GNU dd também suporta busca em bytes, para que você possa retomar exatamente, independentemente do tamanho do bloco:

dd if=/dev/urandom of=/dev/disk/by-uuid/etc bs=1M \
   seek=238048755782 oflag=seek_bytes

Um tamanho de bloco maior deve ajudar nas velocidades, mesmo em dispositivos lentos /dev/urandom.

Se você estiver procurando por alternativas mais rápidas, poderá cryptsetup plainOpencom uma chave aleatória e zerá-la, ela deve bater /dev/urandompor uma ordem de magnitude (sem AES-NI) ou até rodar a toda velocidade (com AES-NI).

Você também pode usar shred -n 1se os dados pseudo-aleatórios forem bons o suficiente para o seu caso de uso. shreddeve poder utilizar a velocidade total do disco, mesmo em uma máquina muito lenta.

frostschutz
fonte
Eu não sabia plainOpenaté agora. Ótimo! Terminei minha luta de uma unidade de 2 TB em cerca de 4 horas, em vez de 256 GB em mais de 12 usando /dev/urandom.
Naftuli Kay
3

Apenas um lembrete para as pessoas que gostariam de copiar em vez de discos apenas randomizing (que não é que comum): você pode usar skip=BLOCKSpara começar a leitura na posição adequada, e seek=BLOCKSpara começar a escrever na posição correta. Ambas as opções usam blocos, não bytes. Ao interromper / reiniciar, é recomendável remover vários blocos, por precaução. Geralmente, vale a pena aumentar o bsvalor acima de 512, pois você pode obter melhor desempenho se ler muitos dados seguidos.

No seu caso, é realmente um valor de bloco para o qual você precisa passar seek. Talvez você deva tentar ajustar bspara ver se consegue aumentar a velocidade, como /dev/randomdeve ser rápido (pseudo-aleatório e sem bloqueio, quando não houver entropia disponível)

Uriel
fonte
0

ddcom um tamanho minúsculo de bloco, como 512 bytes, provavelmente será muito mais lento que o rendimento máximo do seu disco. Use um tamanho de bloco mais alto (em um palpite, eu diria que alguns MB) para obter um bom desempenho. Ou use cat- no Linux , achei cattão rápido quanto ddcom o tamanho ideal de bloco quando um único disco estava envolvido (não sei se isso também vale para o OSX).

Para descobrir até onde catchegou, execute lsof -p1234onde 1234 é o ID do catprocesso.

Para retomar de uma posição, use

{ dd bs=1 seek=123456; cat /dev/urandom; } >/dev/disk/…

onde 123456 é o deslocamento em bytes.

Gilles 'SO- parar de ser mau'
fonte
0

Clonando um disco:

Expandindo esta resposta a partir deste thread, é assim que se pode clonar um disco inteiro e continuar:

Este exemplo é otimizado para copiar de uma unidade rotativa de 5400 rpm para um SSD em um sistema específico. gddrepresenta GNU dd:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' bs=4M status=progress
247426187264 bytes (247 GB, 230 GiB) copied, 2082 s, 119 MB/s
59012+0 records in
59011+0 records out
247510073344 bytes (248 GB, 231 GiB) copied, 2082.92 s, 119 MB/s

Posso retomar isso de duas maneiras:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' \
bs=4M \
seek=59011 skip=59011 \
status=progress

Ou:

> sudo gdd 'if=/dev/rdisk3' 'of=/dev/rdisk6' \
bs=4M \
seek=247510073344 skip=247510073344 \
oflag=seek_bytes iflag=skip_bytes \
status=progress

No primeiro exemplo, a razão pela qual usamos 59011e não 59012é porque 59011é quantos registros de tamanho de bloco foram totalmente copiados antes de serem interrompidos. (registros gravados).

hmedia1
fonte