エラーのない領域でddrescueの方が速いのになぜddrescueが遅いのですか？
この質問は、救出されるデバイスでのddrescueの最初のパスに対処します。
1.5TBのハードディスクを救出する必要がありました。
私が使用したコマンドは：
# ddrescue /dev/sdc1 my-part-img my-part-map
ディスクの適切な領域でレスキューが（オプションのパラメーターなしで）開始されると、読み取り速度（ "current rate"）は約18 MB /秒のままになります。
時々少し遅くなりますが、その後この速度に戻ります。
ただし、ディスクの不良領域に遭遇すると、速度が大幅に低下し、18 MB /秒に戻ることはありませんが、問題なく50 GBの良好なディスクを読み取った後でも、約3 MB /秒のままです。 。
奇妙なことに、現在3 MB/sで良好なディスク領域をスキャンしているときに、ddrescueを停止して再起動すると、18 MB/sの高い読み取り速度で再起動します。 3 MB /秒でddrescueを停止して再起動することで、実際に約2日間節約しました。最初のパスを完了するために8回実行する必要がありました。
私の質問は、なぜddrescueがそれ自体で最高速度に戻ろうとしないのかです。ドキュメントで明確に述べられているように、簡単な領域を最初にすばやく実行するというポリシーを考えると、それは何をすべきかであり、私が観察した動作はバグのようです。
私はこれがオプション-aまたは--min-read-rate=…で処理できるかどうか疑問に思っていましたが、 the manual は非常に簡潔で、私にはわかりませんでした。さらに、このオプションの読み取り速度をどのように選択すべきかがわかりません。 18 MB /秒以上である必要がありますか？
それでも、それを指定するオプションがあっても、これがデフォルトでは行われていないことに驚いています。
メタノート
2人のユーザーが、主に意見に基づくものであるという理由で質問を閉じるために投票しました。
それがどんな意味か知っていただければ幸いです。
実際の例で重要なソフトウェアの動作を数値精度で説明し、ドキュメントに記載されている主要な設計目標を達成していないことを簡単に示します（簡単な部分をできるだけ早く実行します）。それを改善することができます。
ソフトウェアは非常に信頼できるソースから正確なアルゴリズムでよく知られており、ほとんどの欠陥はずっと前に取り除かれたと思います。したがって、私はこの予想外の振る舞いについて考えられる既知の理由を専門家に尋ねています。この問題について私自身は専門家ではありません。
さらに、問題を解決するためにソフトウェアのオプションの1つを使用する必要があるかどうかを尋ねます。これは、さらに正確な質問です。そして、そのドキュメントが見つからなかったので、詳細な側面（このオプションのパラメーターの選択方法）を求めます。
私は自分の仕事に必要な事実ではなく、意見を求めています。そして私は、意見ではなく実験的な事実で動機付けをしています。
私はこれがオプション-aまたは--min-read-rate =で処理できるかどうか疑問に思っていましたが、マニュアルは非常に簡潔なので、確信が持てませんでした。さらに、このオプションの読み取り速度をどのように選択すべきかがわかりません。 18 MB /秒以上である必要がありますか？
--min-read-rate=オプションが役立つはずです。最近のドライブは内部エラーチェックに多くの時間を費やす傾向があるため、速度が極端に低下しますが、これはエラー状態として報告されません。
50 GBの正常なディスクを問題なく読み取った後でも。
つまり、問題が発生しているかどうかもわかりません。ドライブに問題がある可能性があり、それを報告しないことにしました。
現在、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が効果的になるほど高く留まることはないと思います。
したがって、できるだけ多くのデータを取得したい最初のパスでは、高速領域を最初に、手動でaverage_rate / 10に設定します。average_rateは、ドライブが無傷である場合のドライブの平均レートです。
たとえば、ここで10Mを使用して（〜100M/sで動作するはずのドライブの場合）、いつでも戻って遅いエリアで運を試すことができます。
私が観察した動作はバグのようです。
バグがある場合はyoでデバッグする必要があります。同じ種類のドライブ障害がなければ、再現するのは困難です。回復モードでスタックしているのは、ドライブそのものでもかまいません。
欠陥のあるドライブを処理するときは、バスのリセットなど、奇妙なことが起こっていないかdmesgも確認する必要があります。一部のコントローラーは、他のコントローラーよりも故障したドライブの処理に劣っています。
手動による介入は避けられないことがあります。
それでも、これがデフォルトでは行われていないことに驚いています。
ほとんどのプログラムには正気なデフォルトがありません。 ddはデフォルトで512バイトのブロックサイズを使用しますが、これはほとんどの場合「間違った」選択です...正気と見なされるものも時間とともに変化する可能性があります。
私は自分の仕事に必要な事実ではなく、意見を求めています。
ddrescueに依存する必要があるよりも、適切なバックアップがある方が良いです。障害のあるドライブからデータを取得することは、そもそも運の問題です。データの回復には、多くの個人的な経験、つまり意見が含まれます。
私たちが持っているほとんどの回復ツールも愚かです。このツールには、中央サーバーに報告するAIがなく、「ああ、この特定のドライブモデルでこの障害パターンを見たことがあるので、戦略を変更しましょう...」のようになります。したがって、この部分は人間が行う必要があります。
これは少しネクロの投稿ですが、これで発生する可能性のある人のために：
私はOPの動作を再現することができ、その-Oフラグ。エラーが発生するたびに入力ファイルを開きます。
残念ながら、エラーが発生した後、〜3 MiB /秒で再開するように見える理由を掘り下げる機会はありませんでしたが、自分の経験を共有したいと思いました。