停止したラップトップからHDDを回復しています(まったく起動しませんでした。ディスクユーティリティは問題はないがディスクをマウントしないと報告しました)。 USBアダプターを介してHDDを接続しました。 ddrescue
を次のように実行します:
Sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log
これまでのところエラーはありませんが、平均読み取り速度は徐々に50KB/sに低下しています。最初は約2MB/sでした。パーティションのサイズは300GBです。これまでのところ、160GBを回復することができました。 MacBookのHFS +パーティションにリカバリしています。
この転送速度が遅い理由は何ですか?それを増やす方法は?
これは、OSXでのddrescue
とUSB転送の動作のようでした。このスレッドのタイトル: 件名:[Bug-ddrescue] ddrescue 10x osxで遅い 。
完全に機能するハードドライブで作業する場合、Linuxでは完全なI/O速度を実行します。デフォルトのコンパイルフラグを使用してosxでコンパイルすると、速度が大幅に遅くなり、Kb/sにクロールする場合があります。出力ファイルが/ dev/nullの場合、問題は解決しません。
同じスレッドにもこの応答がありました。
私の経験とOS Xでのテストでは、生のキャラクターデバイス
/dev/rdisk…
にアクセスすることが常に望ましいです。また、コピーブロックサイズを大きく設定することで、転送速度をさらに向上させることができます。 512KiB(ddrescue -c 1Ki
)のサイズで、ほとんどの場合に最高の結果が得られました。また、OS Xのrawキャラクターデバイスにはサイズが定義されているため、初回実行時でも簡単に使用できます。 (少なくともこの時点では、
ddrescue
に関する既存のドキュメントのrawデバイスに関する注記はOS Xには適用されません。)
ddrescue
やdd
などの他のユーティリティはOS Xでも同じ動作をするため、これはcat
のバグではないと思います。/ dev/disk…ブロックデバイスにアクセスすると、使用されるコピーブロックサイズに関係なく、速度がかなり遅くなります。一方、/ dev/rdisk…rawキャラクターデバイスの読み取り速度は、選択したコピーブロックサイズに大きく依存します。
- 512バイト(
ddrescue -c 1
、dd
のデフォルト)が最も低速です。- 4096バイト(
ddrescue -c 8
、dd bs=4K
)に設定すると、/ dev/diskにアクセスするのと同じ低速になります…- ddrecueのデフォルトの128セクター(= 64KiB、
ddrescue -c 128
、dd bs=64K
)は、かなり良い結果をもたらします。- さらに乗算すると(最大
ddrescue -c 1Ki
/dd bs=512K
)、最大速度になります(ほとんどの場合/dev/disk…
より8〜12倍高速)。- それを上回っても、私のテストでは転送速度はそれ以上向上しませんでした。時にはそれも減少しました。
これらは私自身の測定の結果であり、結果はメディアやIO使用するハードウェアによって異なります。他のユーザーが経験を共有した場合、トピックのより良い画像を得ることができます。
MacOSのHFS+
ファイルシステムについてはよくわかりませんが、Linuxミントを実行しているラップトップでUSBスティックから500 GBの内蔵ハードドライブ(SATA経由で接続)を救出し、救出を保存した経験をしましたexFat
でフォーマットされたUSBハードドライブのイメージとログファイルは、かなりゆっくりと開始されました(1〜2 MB /秒)。レスキュー画像ファイルが大きくなるほど遅くなるようです。
次に、レスキューイメージとログファイルを別の一時的な場所に移動し、ext4
ファイルシステムでUSBハードドライブを再フォーマットし、ファイルをその上に戻し、ddrescueプロセスを再開しました。現在は1〜20 MBで実行されています/秒(変動しますが、平均で約7MB /秒)!
exFat
は、非常に大きなファイル(数百ギガバイト)ではうまく機能しないようです。すでに述べたように、これがHFS+
にも当てはまるかどうかはわかりませんが、ext4
を試してみたいと思うかもしれません。