Esta questão aborda a primeira passagem do ddrescuedispositivo a ser resgatado.
Eu tive que resgatar um disco rígido de 1,5 TB.
O comando que 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.
De vez em quando diminui um pouco, mas depois volta a essa velocidade.
No entanto, quando encontra uma área ruim do disco, pode desacelerar significativamente e nunca mais volta aos 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 ele está verificando uma boa área de disco a 3 MB/s, se eu parar ddrescuee reiniciá-lo, ele reinicia na taxa de leitura mais alta de 18 MB/s. Na verdade, economizei cerca de 2 dias parando e reiniciando ddrescue
quando estava em 3 MB/s, o que tive que fazer 8 vezes para terminar a primeira passagem.
Minha pergunta é: por que é que ddrescuenão vai tentar voltar para a velocidade máxima por conta própria. Dada a política, explicitamente declarada na documentação, de fazer primeiro e rápido as áreas fáceis, é isso que deve ser feito, e o comportamento que observei me parece ser um bug.
Fiquei me perguntando se isso pode ser tratado com a opção
-aou , --min-read-rate=… mas o manual é tão conciso que eu não tinha certeza. Além disso, não entendo em que base se deve escolher uma taxa de leitura para esta opção. Deve ser os 18 MB/s acima?
Ainda assim, mesmo com uma opção para especificá-lo, estou surpreso que isso não seja feito por padrão.
Metanota
Dois usuários votaram para fechar a pergunta por ser principalmente baseado em opinião.
Gostaria de saber em que sentido é?
Descrevo com alguma precisão numérica o comportamento de um software importante em um exemplo real, mostrando claramente que ele não atende a um objetivo principal de projeto declarado em sua documentação (fazer as partes fáceis o mais rápido possível), e esse raciocínio muito simples poderia melhorar isso.
O software é bem conhecido, de uma fonte muito confiável, com algoritmos precisos, e espero que a maioria dos defeitos tenha sido eliminada há muito tempo. Portanto, estou pedindo aos especialistas uma possível razão conhecida para esse comportamento inesperado, não sendo um especialista nesse assunto.
Além disso, pergunto se uma das opções do software deve ser usada para resolver o problema, que é uma questão ainda mais precisa. E peço um aspecto detalhado (como escolher o parâmetro para esta opção) já que não encontrei documentação para isso.
Estou pedindo fatos que preciso para o meu trabalho, não opiniões. E eu o motivo com fatos experimentais, não com opiniões.
A
--min-read-rate=opção deve ajudar. As unidades modernas tendem a gastar muito tempo em sua verificação interna de erros, portanto, embora a taxa diminua extremamente, isso não é relatado como condição de erro.O que também significa: você nem sabe mais se há problemas. A unidade pode ter um problema e decidir não denunciá-lo.
Agora,
ddrescuesuporta o uso de um valor dinâmico--min-read-rate=, deinfo ddrescue: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, acho que o average_rate nunca permanece alto o suficiente para ser eficaz.
Então, em uma primeira passagem, quando você quer pegar o máximo de dados possível, áreas rápidas primeiro, eu apenas configuro
average_rate / 10manualmente, average_rate sendo qual seria a taxa média da unidade se ela estivesse intacta.Então, por exemplo, você pode ir com
10Maqui (para uma unidade que deve ir a ~ 100M/s) e então você sempre pode voltar e tentar a sorte com as áreas lentas mais tarde.Se você tem um bug, então você tem que depurá-lo. É difícil reproduzir sem ter o mesmo tipo de falha de unidade. Também pode ser a própria unidade que está presa em algum modo de recuperação.
Ao lidar com unidades defeituosas, você também deve verificar
dmesgse há coisas estranhas acontecendo, como reinicializações de barramento e similares. Alguns controladores também são piores em lidar com unidades com falha do que outros.Às vezes, a intervenção manual simplesmente não pode ser evitada.
A maioria dos programas não vem com padrões sãos.
ddainda usa o tamanho de bloco de 512 bytes por padrão, que é a escolha "errada" na maioria dos casos... O que é considerado sensato também pode mudar com o tempo.Ter bons backups é melhor do que ter que confiar no
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 são estúpidas. A ferramenta não possui uma IA que se reporta a um servidor central e diz "Ah, eu já vi esse padrão de falha nesse modelo de unidade específico antes, então vamos mudar nossa estratégia ...". Então essa parte tem que ser feita por humanos.
este é um post meio de necro, mas para qualquer um que possa passar por isso:
Consegui reproduzir o comportamento do OP e consegui que o ddrescue retomasse sua velocidade máxima de leitura usando seu
-Osinalizador, que reabre o arquivo de entrada após cada erro.Infelizmente, não tive a chance de descobrir por que parece retomar a ~ 3 MiB/s após encontrar um erro, mas pensei em compartilhar minha experiência.