ddrescueでオンザフライの画像を圧縮できないのはなぜですか？
GNUのddrescueを使用して、死にかけているハードドライブ上のファイルを回復しようとしています。ドライブはかなり大きく（1TB）、イメージを保存する必要があるのは別の1TBドライブだけです。
ddrescueは、-Sオプションを使用しても、ディスク容量に関するエラーで、終わり近くで失敗します。
作成時に画像を圧縮できないのはなぜですか？ ddおよびdd_rescueで可能です。
また、man ddrescueは、-Sオプションがすべてのシステムで機能するとは限りませんが、自分のシステムで機能するかどうかを確認するにはどうすればよいですか？
gddrescueはファイルを順番にイメージしません-ファイルは戻って再試行し、空白を埋めます。これが、ファイルを他の何かに効果的にパイプできない理由だと思います。 manページで詳しく説明します
GNU ddrescueは、進行中のレスキューのステータスを効率的に管理し、最初に良い部分をレスキューしようとし、後で悪い（または遅い）領域内の読み取りをスケジュールします。これにより、障害が発生したドライブから最終的に回復できるデータの量が最大化されます。
標準のddユーティリティを使用して、障害が発生したドライブからデータを保存できますが、データを順番に読み取るため、エラーがドライブの先頭にある場合は、何も救出せずにドライブが消耗する可能性があります。
他のプログラムは、エラーを見つけると小さなサイズの読み取りに切り替えますが、それでもデータを順番に読み取ります。これは悪い考えです。なぜなら、エラー領域からできるだけ早く抜け出すのではなく、エラー領域でより多くの時間を費やし、表面、ヘッド、およびドライブのメカニズムに損傷を与えることを意味するからです。この動作により、残りの適切なデータをレスキューする可能性が低くなります。
その設計によるものであり、残念ながら、解決策はより大きなドライブを取得することです。 -S引数が機能するには、ソースドライブの使用済みスペースがデスティネーションドライブよりも小さくなければならないと思います。
ddrescueで作成された画像をオンザフライで圧縮することは可能です。つまり、ddrescueは数回のパスで通過するため、シーク可能な宛先が必要です（したがって、@ JourneymanGeekが で説明しているように、後方にジャンプして以前のギャップを埋める機能が必要です。彼の答え ）。これは、パイプがシークできないため、出力としてパイプを使用できないことを意味します。したがって、圧縮プログラムにパイプすることはできません。
これを回避する1つの方法は、透過的な圧縮を使用することです。一部のファイルシステム（特にBtrfsなど）は、この組み込みを提供します。または、ファイルシステムドライバーを使用して、透過的でシーク可能な圧縮ストレージを提供することもできます。 fusecompress 。