이 문제는 해결되었습니다처음으로ddrescue
구출할 장비에 대해.
1.5TB 하드 드라이브를 구해야 했습니다.
내가 사용하는 명령은 다음과 같습니다
# ddrescue /dev/sdc1 my-part-img my-part-map
디스크의 양호한 영역(선택적 매개변수 없이)에서 복구를 시작할 때 읽기 속도(" current rate
")는 약 18MB/s로 유지됩니다.
가끔 속도가 약간 느려졌다가 다시 원래 속도로 돌아옵니다.
그러나 디스크의 불량 섹터가 발생하면 속도가 크게 느려지고 다시는 18MB/s로 돌아가지 않지만 50GB의 양호한 디스크를 읽은 후에도 약 3MB/s를 유지합니다. 문제 없습니다.
이상한 점은 현재 디스크의 좋은 영역을 3MB/s로 스캔하고 있는데, 중지했다가 ddrescue
다시 시작하면 18MB/s의 더 높은 읽기 속도로 다시 시작된다는 것입니다. 실제로 3MB/s에 도달했을 때 중지했다가 다시 시작하여 약 2일을 절약했습니다. ddrescue
첫 번째 패스를 완료하기 위해 8번을 수행해야 했습니다.
내 질문은: 왜 ddrescue
스스로 최고 속도로 돌아가려고 하지 않는가입니다. 쉬운 영역을 먼저 신속하게 완료하라는 문서에 명확하게 명시된 정책을 고려할 때 이것이 수행되어야 하는 작업이며, 내가 관찰한 동작은 나에게 버그처럼 보입니다.
-a
이 문제 를 처리할 수 있는 옵션이 있는지 궁금합니다
--min-read-rate=…
.수동너무 간결해서 잘 모르겠습니다. 게다가 이 옵션의 읽기 속도를 어떤 기준으로 선택해야 하는지 이해가 되지 않습니다. 18MB/s 이상이어야겠죠?
하지만 이를 지정할 수 있는 옵션이 있음에도 불구하고 이것이 기본적으로 수행되지 않는다는 사실에 놀랐습니다.
메타 주석
질문은 주로 의견을 기반으로 했기 때문에 두 명의 사용자가 질문을 종료하기로 투표했습니다.
그게 무슨 뜻인지 알고 싶어요?
나는 실제 예에서 소프트웨어의 중요한 부분의 동작을 어느 정도 수치적으로 정확하게 설명하며, 문서에 명시된 주요 설계 목표(쉬운 부분은 가능한 한 빨리 완료)를 충족하지 못한다는 점을 분명히 보여줍니다. 간단한 추론으로 이를 개선할 수 있습니다.
이 소프트웨어는 잘 알려져 있고 매우 신뢰할 수 있는 소스에서 제공되었으며 정확한 알고리즘을 갖추고 있으며 대부분의 결함이 오래 전에 제거되었으면 좋았을 것입니다. 그래서 저는 이 예상치 못한 동작의 알려진 가능한 원인에 대해 전문가에게 물었습니다. 하지만 저는 이 주제에 대한 전문가는 아닙니다.
또한 문제를 해결하기 위해 소프트웨어의 특정 옵션을 사용해야 하는지 물었는데 이는 매우 정확한 질문이었습니다. 이에 대한 문서를 찾지 못했기 때문에 자세한 측면(이 옵션에 대한 매개변수를 선택하는 방법)을 요청합니다.
나는 직업에 대한 의견이 아닌 사실을 요구하고 있습니다. 의견보다는 실험적인 사실로 동기를 부여합니다.
답변1
이 문제를 처리하기 위해 -a 또는 --min-read-rate= 옵션을 사용할 수 있는지 궁금합니다. 하지만 설명서가 너무 간결해서 잘 모르겠습니다. 게다가 이 옵션의 읽기 속도를 어떤 기준으로 선택해야 하는지 이해가 되지 않습니다. 18MB/s 이상이어야겠죠?
이 --min-read-rate=
옵션이 도움이 될 것입니다. 최신 드라이브는 내부 오류 검사에 많은 시간을 소비하는 경향이 있으므로 속도가 크게 느려지더라도 이는 오류 상태로 보고되지 않습니다.
50GB의 양호한 디스크도 문제 없이 읽을 수 있습니다.
이는 또한 문제가 있는지조차 알 수 없다는 의미이기도 합니다. 드라이브에 문제가 있을 수 있으며 문제를 보고하지 않기로 결정했습니다.
이제 다음 에서 ddrescue
동적 값이 지원됩니다 .--min-read-rate=
info ddrescue
If BYTES is 0 (auto), the minimum read rate is recalculated every
second as (average_rate / 10).
하지만 내 경험상 자동 설정은 별로 도움이 되지 않는 것 같다. 드라이브가 막히면, 특히 처음에 이런 일이 발생하면 평균 속도가 이것이 효과적일 만큼 충분히 높게 유지되지 않을 것이라고 생각합니다.
그래서 첫 번째 패스에서는 최대한 많은 데이터를 얻고 싶을 때 먼저 패스트 존에서 그냥 average_rate / 10
수동으로 설정했고 평균 속도는 드라이브가 손상되지 않았을 때의 평균 속도입니다.
예를 들어 여기에서(약 100M/s로 실행되어야 하는 드라이브의 경우) 선택한 10M
다음 나중에 언제든지 돌아가서 더 느린 영역에서 행운을 시험해 볼 수 있습니다.
내가 관찰한 행동은 버그인 것 같습니다.
그럼 오류가 나면너디버깅해야 합니다. 동일한 유형의 드라이브 오류 없이는 재현이 어렵습니다. 드라이브 자체가 일종의 복구 모드에 갇혀 있을 수도 있습니다.
결함이 있는 드라이브를 다룰 때는 dmesg
버스 재설정 등 이상한 일이 일어나고 있는지도 확인해야 합니다. 일부 컨트롤러는 실패한 드라이브를 처리하는 데 있어서 다른 컨트롤러보다 더 나쁩니다.
수동 개입이 불가피한 경우도 있습니다.
그럼에도 불구하고 이것이 기본적으로 수행되지 않는다는 것에 놀랐습니다.
대부분의 프로그램에는 적절한 기본 설정이 없습니다. dd
기본값은 여전히 512바이트 블록 크기를 사용하는 것인데, 이는 대부분의 경우 "잘못된" 선택입니다. 합리적이라고 간주되는 것도 시간이 지남에 따라 변경될 수 있습니다.
나는 직업에 대한 의견이 아닌 사실을 요구하고 있습니다.
좋은 백업을 갖고 있는 것이 그들에게 의존하는 것보다 낫습니다 ddrescue
. 실패한 드라이브에서 데이터를 검색하려면 먼저 운이 필요합니다. 데이터 복구에는 많은 개인적인 경험과 의견이 필요합니다.
우리가 가지고 있는 대부분의 복구 도구 역시 멍청합니다. 이 도구에는 중앙 서버에 보고하는 인공 지능이 없으며 "아, 이전에 이 특정 드라이브 모델에서 이러한 실패 모드를 본 적이 있으므로 전략을 바꾸자..."와 같은 내용입니다. 그래서 이 부분의 일은 인간이 해야 한다.
답변2
이것은 약간 괴상한 글이지만, 이런 상황에 직면할 수 있는 사람을 위해:
-O
OP의 동작을 재현하고 각 오류 후에 입력 파일을 다시 여는 플래그를 사용하여 ddrescue가 최대 읽기 속도를 복원하도록 할 수 있었습니다 .
안타깝게도 오류 발생 후 ~3MiB/s 속도로 복구되는 것처럼 보이는 이유를 자세히 알아볼 기회는 없었지만 내 경험을 공유하고 싶다고 생각했습니다.