Como posso fazer o dd rodar mais rápido?

Question

Eu tenho um Samsung XE303C12 e tenho executado o Arch Linux ARM nele de um cartão SD. A tabela de partições do cartão SD é assim:

1. Uma partição do kernel do SO Chrome à qual o kernel do ALARME envolvido pelo vboot está ocupado.
2. Uma partição ext2 que eu usaria para configurar o U-Boot sempre que ele fosse instalado na partição 1 em vez do kernel do Arch Linux.
3. O sistema de arquivos raiz que eu instalei o Arch Linux para.

Uma tentativa recente de atualizar todos os pacotes de uma só vez acabou corrompendo o sistema de arquivos raiz. Eu vi alguma mensagem sobre o flash do kernel para alguma partição no cartão SD e sistema de arquivos não ser montado somente leitura ou leitura-gravação ou algo assim. Eu tentei corrigi-lo com fsck , o que me levou várias vezes para o que fazer com inodes, mas uma vez eu percebi que provavelmente ia me perguntar isso para cada inode na partição, eu corri fsck -y /dev/mmcblk1p3 . Isso percorreu talvez várias centenas de inodes até ser interrompido. Não me lembro da mensagem de erro.

Na esperança de preservar os dados para recuperação futura, estou fazendo o backup de /dev/mmcblk1p3 em um sistema de arquivos FAT32 em uma unidade USB usando dd . Como o FAT32 não pode conter arquivos maiores que 4 GiB, decidi dividi-lo em segmentos usando alguns códigos de shell e loops.

Pulando para a frente de algumas coisas, percebi que dd é mais rápido no início do processo (usei bs definido para múltiplos maiores de 512 para torná-lo mais rápido), então o primeiro segmento de 64 MiB seria gravado no sistema de arquivos USB em 3 segundos e ficaria progressivamente mais lento a cada iteração. Descobri que isso ocorre porque o cache de disco é preenchido.

Eu procurei uma maneira de liberar o cache para dd e me deparei com esta postagem no site do Unix Stack Exchange. A resposta principal diz para fazer sync; echo 3 > /proc/sys/vm/drop_caches . Um comentário sobre essa resposta observa que essa configuração não é pegajosa e o link nesse comentário me deu a ideia de fazer echo 3 > /proc/sys/vm/drop_caches antes de cada iteração de dd . Eu tentei isso e dd ainda caiu em velocidade de cópia.

A segunda solução mencionada na resposta do primeiro post foi executar dd com iflag=direct como uma maneira de ignorar o cache. Eu fiz isso, mas também usei oflag=direct , já que imaginei que o cache se aplicaria tanto à cópia do cartão SD quanto à gravação no USB. Este comentário dizia que nocache deve ser usado em vez de direct , então tentei também. Ambos os métodos sofreram a mesma queda de ~ 17 MB / s para ~ 1-3 MB / s.

Eu estou supondo que eu possa não estar usando esses métodos corretamente, então existe alguma maneira de liberar o cache de forma confiável a cada iteração para tornar dd mais rápido ou alguma maneira de simplesmente não usar o cache?

    

Answer 1

Contanto que o tamanho do bloco ( bs ) usado com dd seja grande o suficiente, ele é realmente limitado apenas pela velocidade do hardware. Eu suspeito que você apenas terá que esperar.

Agora eu preciso de uma calculadora ... não consigo encontrar uma, apenas bc . Então você está usando um bs= de 2 para o poder de 25 ... então, cerca de 33 milhões, isso é grande o suficiente (fyi, usando um pequeno bs como 1 ou 512 normalmente irá desacelerar o dd para um rastreamento). / p>

É possível, até provável, que o cartão SD e / ou a unidade USB não sejam lidos & escreva mais rápido. A gravação inicial "rápida" provavelmente está apenas preenchendo um cache de gravação, e a escrita real é sempre a mesma velocidade lenta. A limpeza do cache primeiro daria a ilusão de gravações mais rápidas por mais algum tempo.

Então o seu Arch instalado em um cartão SD está completamente corrompido, e o sistema de arquivos severamente danificado, e você já executou o fsck algumas vezes ... Eu acho que consertar a instalação é quase impossível agora, e um novo instalar seria 1000x mais rápido & mais fácil.

Se você puder montá-lo & copie todos os dados que valem a pena, por que não fazer isso agora e esquecer a recuperação posterior? Dados importantes devem sempre ter um backup de qualquer maneira, então não deveria haver muito o que fazer.

FYI, Você também pode comprimir a imagem dd antes de escrevê-la, gz canaliza muito bem e economizará muito espaço se houver muitos zeros no espaço livre, mas isso faz com que a montagem imagem mais tarde mais difícil. O Squashfs também pôde gerar imagens de todo o disco, para acesso somente leitura montável depois.

[Pode muito bem colocar isso em uma "resposta"]