PBG4 内蔵HDDトラブル時の対応

Question

レベル 1

0 ポイント

PBG4 内蔵HDDトラブル時の対応

質問が２つあります。まず状況を説明します。

Powerbook G4 の内蔵ハードディスク(Toshiba　80GB)が認識されず、fsckをかけても、invalid nodeで修復不可能となりました。新しい内蔵HDDを購入して、OSXを再インストールしました。ただ元のHDDは3年位バックアップをとっていなかったので、USB接続HDDケースにいれ、外付けでPBに接続しました。

mountはもちろんしませんが、ターミナルでdiskutil listと打つと、partition名、サイズとも正常に示されました。

この後、行ったことは「結局，死んだiBookのHDのデータの救出ができました」https://discussionsjapan.apple.com/message/100078236#100078236

と結果的に同じことになると思いますが、この情報を知らなかったので、海外のサイトを参考にして別のやり方で行いました。またDisk Warriorは試していませんが、一発で解決したかもしれません。

まずfreeのGNUソフトddrescue(http://www.gnu.org/software/ddrescue/ddrescue.html)が、ddやdd_rescueよりも優れていると言うことで、インストールして、diskutil listの出力を参考にして、ターミナルを開いて

sudo ddrescue -n /dev/disk1 ~/rescued.dmg ~/logfile.txt

sudo ddrescue -r 1 /dev/disk1 ~/rescued.dmg ~/logfile.txt

sudo ddrescue -R /dev/disk1 ~/rescued.dmg ~/logfile.txt

等として、ディスクのバックアップイメージ ~/rescued.dmg を数日間かけて作りました。I/O errorで結構虫食い状態で読めなかったところも、２０箇所近くありましたが、全部足しても17キロバイト以下になりました。

試していませんが、Data Rescue 3のクローン機能を使えば、手順は簡単に（ただし時間はおなじように非常にかかるかも）同じことが出来るのではないかと思います。

この後

sudo hdiutil attach -nomount ~/rescued.dmg

とマウントしないで、/dev/に割り当てます。結果はdiskutil listでも確認できます。

この情報を元にマウントするために

mkdir /Volumes/rescuedHD

sudo /System/Library/Filesystems/hfs.fs/hfs.util -MU /dev/disk2s3 /Volumes/rescuedHD fixed readonly nosuid nodev

(２回目以後はなぜかエラーが出て、マウントできないので

sudo mount_hfs -o nodev,nosuid,rdonly -j /dev/disk2s3 /Volumes/rescuedHD

とした）

とすると、幸運にもマウントできました。

今回のケースの場合、ログファイル~/logfile.txtで示されるI/O errorが起きた領域はディスクイメージ~/rescued.dmg のvolume headerの中のcatalog情報を参照すると、すべて、２番目のcatalog fileのなかにあることが確認できました。

このあと、rsync等で全ディスクのバックアップをしたところ、/Users以下の領域ではI/Oerrorが全く出なかったので、一安心でした。

質問は以下の２点です。

（１）トラブルの起きた内蔵HDDを接続して『コンソール』アプリケーションでログを確認すると、必ずfsck_hfsの実行が確認されます。fsck_hfsは、物理的に正常でない所を繰り返し読みに行くので、HDDの寿命を縮めると考えられ、出来たら避けたいのですが、その方法を教えてくれませんか？

OSはOSX 10.4.11、また別にOSX 10.5.8が利用できます。

ボリューム名はMacintoshHDなので、/etc/fstabに

LABEL=MacintoshHD none hfs ro,noauto

LABEL=MacintoshHD\0401 none hfs ro,noauto

等と書いて、再起動してみましたが、挙動は変わりません。

（２）ddrescueのマニュアルに、fill modeで

sudo ddrescue --fill=- --synchronous /dev/zero /dev/disk1 ~/logfile.txt

等とすれば、読み取りの出来なかったsectorsだけをドライブが自動的に、他の場所に置き換えてくれる(remap)可能性があると書いてあります。

もしこれが可能なら、障害の起きたHDDは少なくともいままでの障害については正常化できると思われます。

今回の東芝の内蔵ディスクの場合、このことが可能でしょうか？

以上、よろしくお願いします。

環境

PowerBook G4 15", PowerPC G4(1.5) 1.67GH

メモリー 2GB、ブートROM 4.9.5f3

システム　Mac OSX 10.4.11(8S165) Darwin 8.11.0

内蔵ハードディスク　74.53GB

"Product Identification" = "MK8026GAX"

"Vendor Identification" = "TOSHIBA"

投稿日 2009/11/07 04:16

返信

Answer 1

はに

レベル 9

78,029 ポイント

2009/11/07 05:25 peach000 への返信

>（１）トラブルの起きた内蔵HDDを接続して『コンソール』アプリケーションでログを確認すると、必ずfsck_hfsの実行が確認されます。

これは壊れたディスクを読もうとする限り必ず実行されます。fsck が実行されるとディスクの寿命が縮むというのは誤解です。毎回fsck が実行されるようなディスクは，既に寿命が尽きてます。今回、ddrescue でデータの読み出しが出来たのなら，大変ラッキーだったと思うべきで、またこのディスクを使うことなど論外です。

> (2) ....

ddrescue のことはよく知りませんが，一般的にいえば，もうこんなディスクは寿命と考えて使うべきではありません。

返信

Answer 2

kanekaka

レベル 1

107 ポイント

2009/11/07 06:03 peach000 への返信

peach000 さんによる書き込み:

質問が２つあります。まず状況を説明します。
（２）ddrescueのマニュアルに、fill modeで
sudo ddrescue --fill=- --synchronous /dev/zero /dev/disk1 ~/logfile.txt
等とすれば、読み取りの出来なかったsectorsだけをドライブが自動的に、他の場所に置き換えてくれる(remap)可能性があると書いてあります。
もしこれが可能なら、障害の起きたHDDは少なくともいままでの障害については正常化できると思われます。
今回の東芝の内蔵ディスクの場合、このことが可能でしょうか？

以上、よろしくお願いします。

ディスクユーティリティでもゼロフォーマットでremapされると思いますけど。

私もそのようなHDDは使いたくないですね。

返信

Answer 3

peach000 作成者

レベル 1

0 ポイント

2009/11/07 06:36 はにへの返信

早速の回答、ありがとうございます。

>>（１）トラブルの起きた内蔵HDDを接続して『コンソール』アプリケーションでログを確認すると、必ずfsck_hfsの実行が確認されます。

>

>これは壊れたディスクを読もうとする限り必ず実行されます。fsck が実行されるとディスクの寿命が縮むというのは誤解です。

今回の物理的障害の起きたハードディスクの場所はカタログファイルの中にありますので、fsckが成功することはまず考えられません。それでそのような”無駄”で有害になりそうなことは出来ればしてほしくないわけです。

この質問をしたわけは、/Users以下のディレトリー領域は多分バックアップできたので、できたら、他の全領域も復元したいと考えたからです。rsyncでエラーの起きたディレトリーは全部で25個です。それで、ddrescueコマンドの----input-positionコマンドを用いてさらに繰り返せば、I/O errorの領域は多分現在の17キロバイトの数分の１になると、経験から思われます。そうすると繰り返し、接続を繰り返す必要があります。ddrescue自体はI/O errorの所をコマンドオプションで指定した回数をこえて読み取りませんが、fsckはカタログファルのツリー構造にしたがって読みに行くと考えられますから、毎回同じ所、しかも障害のあるところを読みに行くのですから、心配になります。URLは忘れましたが、一度障害が起きた場所を読み/書きすると（障害の程度にもよるが）その領域が広がるという内容を読んだ記憶があります。

知りたいのはディスクイメージのコマンド

sudo hdiutil attach -nomount ~/rescued.dmg

の-nountに相当するようなことが実際のボリュームにもできないかと言うことです。このコマンドも-nomountオプションがないと、mountを試みて、自動的にfsckが立ち上がってしまうように思えます。

>> (2) ....

>

>ddrescue のことはよく知りませんが，一般的にいえば，もうこんなディスクは寿命と考えて使うべきではありません。

その通りと思います。ただ、I/O errorの起きない領域を読み取るときには、ほとんど音もしないので、ひょっとしたらしばらくは使えるのではないかと思ったわけです。（1）にも書いた事情でまだ試せませんが、それが1段落ついた辞典で試してみたいと思います。

返信

Answer 4

kanekaka

レベル 1

107 ポイント

2009/11/07 07:24 peach000 への返信

/Usersが取り戻せただけで，私なら満足してしまうので，浅はかな回答をしてしまったようですね。

破損しているのがカタログファイルの一部とのことで，不良セクタのremapで生き残っているカタログファイルとその参照先ファイルを復旧しようということですね。

何のアドバイスもできませんが，詳しい方のアドバイスが得られることをお祈りします。

うまくいくことを期待しておりますので，是非とも結果をお知らせください。

返信

Answer 5

peach000 作成者

レベル 1

0 ポイント

2009/11/07 09:03 kanekaka への返信

kanekaka 様

あ、すみません、誤解させる書き方だったかもしれません。

I/O errorの領域のデータを読み出そうとしているわけではありません。

ddrescueがI/O errorの領域と報告するのは、本当のエラーの所と（エラーのために）まだ試みてない領域の合わさったところです。後者の領域を--input-position等のオプションを変えながら試行錯誤を繰り返し、可能な限り減らそうと言うことです。読み取れない領域はもちろん残りますが、ほとんどがシステムの領域（OS インストールやソフトウエアアップデートでのみ変えられる領域）なので、2つのディスクの内容を比較することにより、読み取れない領域が少なければ、多分復元できるだろうということです。

だったら、再インストールしたPBに復元した/Usersをマージする方が早いというご意見もあるかとは思いますが、/Applicationsや/usr,/optさらに/Libraryにも適当にインストールしたものがあり、もし元のシステムが復元するならそれにこしたことはないというのが状況です。

回答を書くうちに、（１）のヒントを思いつきました。一番最初に書いたなかで、　/etc/fstabに

LABEL=MacintoshHD none hfs ro,noauto

等を書いても、状況は変わらないといいましたが、考えてみたら、hfsですから、LABELの代わりに、UUIDを指定して、明日やってみます。うまくいったら、また報告します。

返信

Answer 6

はに

レベル 9

78,029 ポイント

2009/11/07 14:55 peach000 への返信

>物理的障害の起きたハードディスクの場所はカタログファイルの中にありますので、fsckが成功することはまず考えられません。それでそのような”無駄”で有害になりそうなことは出来ればしてほしくない

カタログファイルの内容と実際のデータが整合してない（結果として読み出せない）ために，fsckが動くのでは？

fsck が動いても，正しいデータが読み出せないなら，その部分は修復不可能なまでに壊れているということでは？

fsckしたくないなら、そういうディスク修復プログラムを作るしかないのでは？ddrescueって，そういう類いのソフトなのでは？

カタログファイルの領域は，ディスクにアクセスしたときに最初に参照される領域です。ディスクをフォーマットすれば，サイズによって自動的に場所は決まってしまいます。そこが壊れているということは，ディスクとしてはもう使えないということでは？たとえ一時的に使えるようになったとしても，また短期間でディスク障害が起こると思います。

返信