Como evitar que o progresso do dd seja insignificante no Linux?

5

Ao executar o comando dd para copiar um ISO no Linux, recebo uma única impressão de progresso que fica aberta por um longo tempo (muitos minutos). Então outro no final.

O problema parece ser que um cache muito grande está sendo usado, o que faz com que dd pense

sudo dd bs=4M if=my.iso of=/dev/sdc status=progress

Saída (a primeira linha mostra por um longo tempo).

1535115264 bytes (1.5 GB, 1.4 GiB) copied, 1.00065 s, 1.5 GB/s
403+1 records in
403+1 records out
1692844032 bytes (1.7 GB, 1.6 GiB) copied, 561.902 s, 3.0 MB/s

Existe uma maneira de impedir que isso aconteça, de modo que a saída do progresso seja significativa?

    
por ideasman42 21.07.2017 / 15:44

1 resposta

11

A partir da primeira linha, podemos dizer que dd leu e escreveu 1,5 GB em um segundo. Mesmo um SSD não consegue escrever tão rápido.

O que aconteceu foi que o dispositivo de bloco / dev / sdc aceitou-o (writeback), mas não o enviou para o disco, mas o armazenou em buffer e começou a gravar no disco na velocidade que o disco pode suportar. Algo como 3 MiB / s.

O sistema não pode armazenar em buffer os dados indefinidamente assim, há apenas tantos dados que ele aceitará manter em estado sujo > não comprometido. Então, depois de um tempo (no seu caso, depois que mais de 1,5 GB foram escritos, mas menos de 2 segundos se passaram (conforme as linhas de progresso são gravadas a cada segundo)), a chamada dd do sistema será bloqueada até que os dados foi liberado para o disco (durante o qual ele não pode gravar mensagens de progresso). Quando isso acontecer, write() pode enviar os poucos megabytes perdidos, e isso acontece em menos de um segundo, então você tem apenas uma linha de progresso extra.

Para ver um comportamento diferente, você pode forçar as gravações a serem síncronas, que não devem retornar, a menos que os dados tenham sido confirmados no disco. Por exemplo, usando dd ou oflag=sync ou oflag=dsync (não que eu recomendaria fazer isso embora).

    
por 21.07.2017 / 16:19

Tags