Por que o ddrescue é lento quando pode ser mais rápido em áreas livres de erros?

Question

Esta questão aborda a primeira passagem de ddrescue no dispositivo a ser resgatado.

Eu tive que resgatar um disco rígido de 1,5 TB.

O comando que eu usei é:

# ddrescue /dev/sdc1 my-part-img my-part-map

Quando o resgate é iniciado (sem parâmetros opcionais) em uma boa área do disco, a taxa de leitura (" current rate ") fica em torno de 18 MB / s.

Ocasionalmente, ele desacelera um pouco, mas volta a essa velocidade.

No entanto, quando encontra uma área ruim do disco, ela pode ficar mais lenta significativamente, e então nunca volta para os 18 MB / s, mas permanece em torno de 3 MB / s, mesmo depois de ler 50 GB de disco bom sem problemas.

A parte estranha é que, quando está escaneando uma boa área de disco a 3 MB / s, se eu parar ddrescue e reiniciá-lo, ele reinicia na taxa de leitura mais alta de 18 MB / s. Eu na verdade, economizou cerca de 2 dias parando e reiniciando ddrescue quando estava indo a 3 MB / s, o que eu tive que fazer 8 vezes para terminar o primeiro passo.

Minha pergunta é: por que é que ddrescue não tentará voltar para o maior velocidade por conta própria. Dada a política, explicitamente declarada na documentação, de fazer primeiro e acelerar o áreas fáceis, é isso que deve ser feito, e o comportamento que observei parece-me ser um bug.

Eu tenho me perguntado se isso pode ser resolvido com a opção -a ou --min-read-rate=… mas o manual é tão conciso que eu não estava certo. Além disso, não entendo com que base se deve escolher um taxa de leitura para esta opção. Deve ser o acima de 18 MB / s?

Ainda assim, mesmo com uma opção para especificá-lo, estou surpreso que isso não seja feito por padrão.

Meta nota

Dois usuários votaram para fechar a questão por ser primariamente opinião com base.

Eu gostaria de saber em que sentido isso é?

Eu descrevo com alguma precisão numérica o comportamento de um importante peça de software em um exemplo real, mostrando claramente que não atende a um grande objetivo de projeto declarado em sua documentação (fazendo as partes fáceis o mais rápido possível), e isso é muito simples raciocínio poderia melhorar isso.

O software é bem conhecido, de uma fonte muito confiável, com precisão algoritmos, e espero que a maioria dos defeitos tenham sido eliminados há muito tempo. Por isso, estou perguntando aos especialistas por uma possível razão conhecida para esse inesperado comportamento, não sendo um especialista eu mesmo sobre esta questão.

Além disso, pergunto se uma das opções do software deve ser usado para resolver o problema, que é ainda mais preciso questão. E peço um aspecto detalhado (como escolher o parâmetro para esta opção) desde que eu não encontrei documentação para isso.

Estou pedindo fatos que preciso para o meu trabalho, não para opiniões. E eu motivá-lo com fatos experimentais, não opiniões.

    

Answer 1

I have been wondering whether this can be dealt with with the option -a or --min-read-rate= ... but the manual is so terse that I was not sure. Besides, I do not understand on what basis one should choose a read rate for this option. Should it be the above 18 MB/s?

A opção --min-read-rate= deve ajudar. As unidades modernas tendem a gastar muito tempo na verificação interna de erros, portanto, embora a taxa fique extremamente lenta, isso não é relatado como uma condição de erro.

even after reading 50 GB of good disk with no problem.

O que também significa: você nem sabe mais se há problemas. A unidade pode ter um problema e decidir não denunciá-la.

Agora, ddrescue suporta o uso de um valor --min-read-rate= dinâmico, de info ddrescue :

 If BYTES is 0 (auto), the minimum read rate is recalculated every
 second as (average_rate / 10).

Mas, na minha experiência, a configuração automática não parece ajudar muito. Uma vez que a unidade fica travada, especialmente se isso acontecer logo no início, eu acho que o average_rate nunca fica alto o suficiente para que seja eficaz.

Então, em uma primeira passagem, quando você quiser obter o máximo de dados possível, as áreas rápidas primeiro, basta defini-las como average_rate / 10 manualmente, average_rate sendo a taxa média da unidade se ela estiver intacta.

Então, por exemplo, você pode ir com 10M aqui (para uma unidade que deve ir a ~ 100M / s) e então você pode sempre voltar e tentar a sua sorte com as áreas mais lentas depois.

the behavior I observed seems to me to be a bug.

Se você tem um bug, então você precisa depurá-lo. É difícil reproduzir sem o mesmo tipo de falha de unidade. Também poderia ser a própria unidade que está presa em algum modo de recuperação.

Ao lidar com unidades defeituosas, você também deve verificar dmesg se houver alguma coisa estranha acontecendo, como redefinições de barramento e coisas do tipo. Alguns controladores também são piores em lidar com unidades com falha do que outros.

Às vezes, a intervenção manual não pode ser evitada.

Even then, I am surprised this is not done by default.

A maioria dos programas não vem com padrões normais. O dd ainda usa blocos de 512 bytes por padrão, o que é a opção "errada" na maioria dos casos ... O que é considerado sensato também pode mudar com o tempo.

I am asking for facts that I need for my work, not opinions.

Ter bons backups é melhor do que depender de ddrescue . Obter dados de uma unidade com falha é uma questão de sorte em primeiro lugar. A recuperação de dados envolve muita experiência pessoal e, portanto, opiniões.

A maioria das ferramentas de recuperação que temos também é estúpida. A ferramenta não tem um AI que reporta a um servidor central, e diz: "Ah, eu vi esse padrão de falha neste modelo de unidade particular antes, então vamos mudar nossa estratégia ...". Então essa parte tem que ser feita por humanos.