現在のステータスを使用してGNU ddrescue（1.18.1）の完了のループ/時間を推定する方法は？
背景/コンテキスト：
現在実行中GNU= ddrescue 1.18.1は、仮想ディスクイメージをdisk2s1パーティションに書き込んでいるときにケーブルが切断されたUSBからデータを回復します。最初は2番目のパーティション（ disk2s2）と3番目のフェーズ（分割）に達したことに注意して、イメージをネットワークストレージに配置しています。
質問：
このフェーズがループすることに気づきました。現在のステータス情報から、発生する可能性が高いループの数を計算する方法はありますか？
ステータス：
更新/編集：
ですから、ddrescueツールを使用して、ループ/完了の時間をどのように見積もるかに、私はまだ非常に興味があります。コメントに従って、現在実行中のdisk2s1パーティションのログファイルの評価を追加しています（disk2s2は14.5時間後に完了し、1人のユーザーが約6時間中断しました）。
完了したパーティションログ
完了したばかりのパーティションについて、ログ検査の結果を次に示します。
リファレンス（ddrescueアルゴリズムのメモ）：
4アルゴリズム
GNU ddrescueはddの派生物ではありません。また、あるデバイスから別のデバイスにデータをコピーするために両方を使用できるという点を除いて、ddとは関係ありません。主な違いは、ddrescueは高度なアルゴリズムを使用して、故障したドライブからデータをコピーし、追加の損傷をできるだけ少なくすることです。
Ddrescueは進行中のレスキューのステータスを効率的に管理し、最初に適切な部分をレスキューしようとし、後で悪い（または遅い）領域内の読み取りをスケジュールします。これにより、障害が発生したドライブから最終的に回復できるデータの量が最大になります。
標準のddユーティリティを使用して、障害のあるドライブからデータを保存できますが、データを順次読み取ります。これにより、ドライブの先頭にエラーがある場合、何も救済せずにドライブが消耗する可能性があります。
他のプログラムはデータをシーケンシャルに読み取りますが、エラーを検出すると小さなサイズの読み取りに切り替えます。これは、エラー領域でより多くの時間を費やし、できるだけ早くそれらから抜け出すのではなく、表面、ヘッド、およびドライブ機構に損傷を与えることを意味するため、これは悪い考えです。この動作により、残りの適切なデータを救う可能性が減少します。
Ddrescueのアルゴリズムは次のとおりです（ユーザーはいつでもプロセスに割り込むことができますが、不良ドライブがカーネルが停止するまでddrescueを長時間ブロックする可能性があることに注意してください）。
1）オプションで、マルチパートまたは以前に中断されたレスキューのステータスを説明するログファイルを読み取ります。ログファイルが指定されていないか、空であるか存在しない場合は、すべてのレスキュードメインを未試行としてマークします。
2）（最初のフェーズ;コピー）入力ファイルの未試行部分を読み取り、失敗したブロックを非トリムとしてマークし、それらを超えてスキップします。遅いエリアを越えてスキップします。スキップされた領域は、後で2つの追加パス（トリミングの前）で試行され、すべてのレスキュードメインが試行されるまで、各パスの後で方向が逆になります。 3番目のパスは、スキップを無効にしたスイープパスです。 （目的は、大きなエラーをすばやく区切り、ログファイルを小さく保ち、トリミングの開始点を作成することです）。未試行の領域のみが大きなブロックで読み取られます。トリミング、分割、再試行はセクターごとに行われます。各セクターは最大2回試行されます。このステップの最初は（通常は大きなブロックの読み取りの一部として、場合によっては単一セクターの読み取りとして）、以下のステップの1つで2番目は単一セクターの読み取りとして。
3）（第2フェーズ、トリミング）読み取りは、最小の非トリミングブロックのリーディングエッジから一度に1セクターずつ、不良セクターが見つかるまで転送します。次に、不良ブロックが見つかるまで、同じブロックの最後のエッジから一度に1セクターずつ逆方向に読み取ります。トリミングされていないブロックごとに、見つかった不良セクターを不良セクターとしてマークし、そのブロックの残りの部分を、読み取ろうとせずに非分割としてマークします。トリミングされていないブロックがなくなるまで繰り返します。 （トリミングされていない大きなブロックは、小さいブロックを連結することによって生成されるため、エッジでの適切なデータの割合は小さくなります）。
4）（第3段階;分割）読み取りは、最大の非分割ブロックの中心から一度に1つのセクターを、不良セクターが見つかるまで転送します。次に、見つかった不良セクターが最初に試行されたものでない場合は、不良セクターが見つかるまで、同じブロックの中心から一度に1セクターずつ逆方向に読み取ります。ログファイルが「--logfile-size」より大きい場合は、ログファイルのエントリ数が「--logfile-size」を下回るまで、最大の非分割ブロックを順次読み取ります。残りのすべての非分割ブロックのセクターが7未満になるまで繰り返します。次に、残りの非分割ブロックを順番に読み取ります。
5）（第4フェーズ;再試行）オプションで、指定された再試行パスの回数に達するまで、不良セクターを再度読み取ってみます。すべての不良セクターは、各パスで1回だけ試行されます。 Ddrescueは、不良セクターが回復不能かどうか、または再試行後に最終的に読み取られるかどうかを認識できません。
6）オプションで、後で使用するためにログファイルを書き込みます。
合計エラーサイズ（ 'errsize'）は、すべての非トリミングブロック、非分割ブロック、および不良セクターブロックのサイズの合計です。コピー段階で増加し、トリミング、分割、再試行中に減少する可能性があります。 ddrescueが失敗したブロックを分割してそれらを小さくすると、エラーの数が増加する一方で、合計エラーサイズが減少する可能性があることに注意してください。
ログファイルは定期的にディスクに保存されます。また、ddrescueが終了したときや中断されたときも保存されます。したがって、クラッシュが発生した場合は、ほとんど再コピーせずにレスキューを再開できます。保存の間隔は、ログファイルのサイズに応じて30秒から5分まで変化します（大きなログファイルはより長い間隔で保存されます）。
また、同じログファイルを、入力ファイルの異なる領域をコピーする複数のコマンド、および異なるサブセットでの複数回のリカバリ試行に使用できます。この例を見てください：
まず、ディスクの最も重要な部分を救出してください。 ddrescue -i0 -s50MiB/dev/hdc hdimage logfile ddrescue -i0 -s1MiB -d -r3/dev/hdc hdimage logfile
次に、いくつかの主要なディスク領域を救出します。 ddrescue -i30GiB -s10GiB/dev/hdc hdimage logfile ddrescue -i230GiB -s5GiB/dev/hdc hdimage logfile
残りを救い出します（すでに行われたことを再コピーしません）。 ddrescue/dev/hdc hdimage logfile ddrescue -d -r3/dev/hdc hdimage logfile
質問は10か月前に行われましたが、いくつかの要因によっては回復サイクルがまだ実行されている可能性があるため、回答は適切である可能性があります。しゃれは意図されていません。
その理由は、時間の見積もりはほとんど不可能ですが、次のような大まかなアイデアが得られる場合があるためです。最も明白な理由の1つは、ドライブが不良セクターを読み取るのにかかる時間を予測できないことです。ddrescueですべてのセクターを読み取って再試行する場合、非常に長い時間がかかる可能性があります。たとえば、私は現在、2週間以上続いている小さな500 GBドライブでリカバリを実行しており、おそらく数日残っている可能性があります。しかし、ドライブは暗号化されており、何かを正常に読み取るために、パーティションテーブル、ブートセクター、およびディスクの他の重要な部分があるすべてのセクターを取得するようにしています。私はddrescueに加えてテクニックを使用して、すべての不良セクターの可能性を高めています。 IOW、完了までの時間を決定するには、あなたのユニークな状況が重要です。
「ループ」の見積もりでは、再試行の回数を意味する場合、それは使用するパラメーターによって決まります。 「パスの総数」を意味する場合は、ここでアルゴリズムについて読むことで簡単に判断できます。 > man ddrescue </ Algorithm：How ddrescue recovering the data
具体的には、ご提供いただいたスクリーンキャプチャの数字についてお話します。他の状況には他の要素が適用される可能性があるため、この情報を一般的なガイドラインとして使用してください。
提供したサンプルで、ddrescueの実行ステータス画面を確認してください。 「errsize」により、問題（レスキュードメイン）の合計「見積もり」を取得します。これは、「まだ読み取られていない」データの量です。サンプルでは345GBです。右下の次の行は「平均レート」です。サンプルでは583kb/sです
「平均レート」がほぼ安定したままであるとすると、これはあと7日であることを意味します。 345 GB /（583 kb * 60 * 60 * 24）= 7.18ただし、問題は583kb/sに依存できないことです。実際には、回復をより深く行うと、ドライブはますます厳しい領域を読み取り、より多くの再試行を行うため、速度が低下します。したがって、指数関数的に終了する時間が増加します。これはすべて、ドライブがどれほどひどく破損しているかによって異なります。
あなたが提供したサンプルは、「正常な読み取り」が10時間以上前であったことを示しています。つまり、ドライブから10時間以上何も取得されていません。これは、ドライブに345GB相当（または一部）のデータショットがあることを示しています。これはあなたにとって非常に悪いニュースです。
対照的に、「S.M.A.R.T」エラーが発生し始めたばかりの2番目の500 GBドライブは、ディスクにディスクにコピーされ（ログファイルは別のドライブにあり）、操作全体に約8〜9時間かかりました。それの最後の部分は減速しました。しかし、それはまだ耐えられます。非常に悪いドライブですが、上記のように、500GBで2週間作業し過ぎており、回復するのに約4〜5％残っています。
HTHおよびYMMV