ddrescueが不良ブロックのスクレイピングでスタックしています...（転送）
不良ブロックがいくつかあるHitachi640GBラップトップハードドライブがあります。ドライブからカチッという音がしないので、ブロックが物理的な不良ブロックであるとは思わない。ハードドライブはNTFSとしてフォーマットされ、Windows7ドライブとして使用されました。ドライブでCHKDSKを3回実行しましたが、複数の孤立したファイルと破損したファイルが報告され、それらの修正が報告されましたが、ドライブは使用している別の動作中のドライブにファイルをコピーできませんでした。
Ddrescueを使用してファイルをレスキューすることにしました。 ddrescueでファイルを復元している2TBのUSBドライブがあります。 Hitachiドライブは、私がddrescueを実行しているiMacにFirewire400で接続されています。
コマンドパラメータを使用します：
Sudo ddrescue -r3 /dev/disk5s2 test.img test.logfile
Ddrescueは数日間正常に動作しているようで、imgファイルはHitachiと同じサイズなので、これも正常のようです。しかし、過去3日間、ドライブの最後のピースと思われるものにddrescueがスタックしています。報告されるエラーサイズは36404KBで、読み取りが成功するのは12時間以上に1回だけです。ターミナルでのddrescue出力のスクリーンショットと、参照用のddrescueログファイルのコピーを添付しています。 ddrescueがアクセスすると、ドライブはハミングを続けますが、これまでのところほとんど進展がありません。
何らかの理由で、ダイレクトディスクアクセスを使おうとすると、ターミナルからエラーが返されました。ダイレクトディスクアクセスが利用できないため、ddrescue操作で使用できませんでした。
Ddrescueの操作を停止して再開する必要がありますか？ハードドライブのこの最後の厄介な領域のデータを試すために、コマンドパラメータを変更する必要がありますか？それとも、ddrescueが取得できないほど本当に破損しているのでしょうか、それとも取得できるのであれば、非常に長い時間がかかるのでしょうか。
この問題に関するアドバイスをいただければ幸いです。
ログファイル出力
[
1
端末出力
[
2
から GNU ddrescue Manual ：
不良ドライブは、カーネルが諦めるまで、ddrescueを長時間ブロックする可能性があることに注意してください
この質問 もあります。そこでの答えは、ドライブを冷やすようにすることを示唆しています。それが良いアドバイスかどうかはわかりませんが。
直接アクセスの問題について：マニュアルにはrawデバイスが記載されています（ 例2 を参照）。 rawコマンド はここで役立ちます。私はddrescueをそのように使用したことがない（つまり、使用しなければならなかった）ことを認めます。