カテゴリー
Mac

Invalid content in journal

OS X Server への ssh や画面共有でのアクセスは問題ないんだけど、メールのリファイルがタイムアウトを起こすようになっていました。たまーに Drobo さんは考え込んでそんな状況になることがあるので、今回もそれかなー、とか思ったのですが、念のため /var/log/system.log を眺めてみると

Oct 17 15:33:07 flora kernel[0]: disk1s2: I/O error.

というのがずらーっと…。だがしかし Drobo Dashboard でみる限り各ドライブのステータスは正常なので、じゃあケーブルとかそんな問題かしらん、と一旦再起動を仕掛けたら、いつまで経っても再起動が完了しない。ま、 I/O error が出てるんならそれ待ちになって刺さるのはありがちだよねー、と電源ケーブルを引っこ抜いて、ついでに埃がすごいことになっていた Drobo を掃除(?)して、接続を確認して電源を入れたら!

Drobo がマウントできなくなっていました…

仕方ないので fsck 、と思ったら OS X では fsck にディスク名を渡すことが出来ないっぽく、全部のディスクをチェックしにいく仕様みたいで、個別のディスクをチェックしたい場合、ファイルシステムにあった fsck (OS X 標準の hfs+ の場合は fsck_hfs) を動かす必要があるみたいです。って /Applications/Utilities/Disk Utility.app でディスク選んで修復選んだほうが簡単ですけど。

なんにしろ経過は /var/log/fsck_hfs.log に吐かれるようです。こんな具合。

/dev/rdisk1s2: fsck_hfs run at Wed Oct 17 16:05:26 2012
/dev/rdisk1s2: ** /dev/rdisk1s2
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-557~393).
   Invalid content in journal
** Checking Journaled HFS Plus volume.
   The volume name is TimeMachine
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
** Checking volume bitmap.
** Checking volume information.
** Repairing volume.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
   The volume name is TimeMachine
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
** Checking volume bitmap.
** Checking volume information.
** The volume TimeMachine was repaired successfully.

/dev/rdisk1s2: fsck_hfs run at Fri Oct 19 03:50:55 2012
/dev/rdisk1s2: ** /dev/rdisk1s2 (NO WRITE)
/dev/rdisk1s2: Executing fsck_hfs (version diskdev_cmds-557~393).
 Invalid content in journal
QUICKCHECK ONLY; FILESYSTEM DIRTY

修復成功してるのに、 FILESYSTEM DIRTY とはこれ如何に。ってこれはまだ素直なログなんでツッコミ入れるだけですんでますが、 Disk Utility.app だと

ディスクの修復に成功しました。
ディスクは破損しています。出来るだけ多くのファイルのバックアップをとってください

という感じの矛盾感満載のメッセージを出してくれるので苛立ち倍増。というかバックアップ取れって言うならまずマウントさせろよってところです。

で、困ったときの Google 頼みってんで “repairing volume rechecking volume” でググってヒットしたページによると

fsck_hfs -ypr /dev/disk1s2

とかしてあげるといいみたい。藁にもすがる勢いで実行してみたましたが、これはどうも catalog B-tree のリビルドをするだけみたいだから、今回のは関係ないんじゃ…。
しかし、画面には

** Rebuilding catalog B-tree.

の文字が踊っているので中止するにもリスクは高い。
ということで今度は Invalid content in journal でググろうとしたんですが、そしたら Drobo を Suggest してくれたので FAQ? と思ったら Drobo のサポートサイトがヒットしました(苦笑)。

曰く

  • Dashboard 上で正常だったら、ファイルシステムが壊れてるね
  • Mac OS X だったら Disk Utility.app で修復してね

修復して駄目なんだよ、と突っ込もうとしたら続きがありました

Note: If you get an error, “invalid content in the journal” from disk utility, try disabling journaling on your Drobo product. Repair your Drobo device with Disk Utility and then turn the journaling back on.

…え? journaling ってフォーマットなしでも無効化できるもんなの? って驚いたんだけど割とよくある質問みたい。やり方は二種類あって

…まぁ、どっちも同じことをしてるっぽいので、どっちにするかは好みの問題っぽいんだけど、それぞれのコマンドの日付をみたら diskutil のほうがタイムスタンプが新しかったのでこっちを採用。この例ではマウントしたボリュームを指定するように見えるけど、マウントしてなくても実行可能でその場合は /dev のディスク名を指定すればいいみたい。で、 Disk Utilities.app や diskutil mountvol はディスクをマウントしようとすると、

  1. fsck を軽くかける(QUICK CHECK)
  2. 問題なければマウント
  3. 問題があったら fsck_hfs

という動きをしているみたいなので、不味かったら勝手に fsck かけるだろう、と disableJournal してからいきなりマウントすることにしました。が

sudo diskutil disableJournal /dev/disk1s2
An error occurred journaling the file system: Couldn't mount disk (-69842)

…げ。
しかし disableJournal には force という心強いオプションが…!!

sudo diskutil disableJournal force /dev/disk1s2
An error occurred journaling the file system: The underlying task reported failure on exit (-69860)

…げげ。
が、しかしググってみるとどうやらここでエラーが出るのはお約束っぽいので心を強くもってマウントを仕掛けてみる…と

読み取り専用でマウントしました。
ディスクは破損しています。出来るだけ多くのファイルのバックアップをとってください

的なメッセージががが!!
マウントできればこちらのもの、ということで試しにいくつかのファイルを開いてみたら問題ないっぽいので

sudo diskutil enableJournal  /dev/disk1s2
Journaling has been enabled for volume TimeMachine on disk1s2

とジャーナルを再度有効化して、 OS ごと再起動!!

/dev/rdisk1s2: fsck_hfs run at Sat Oct 20 10:32:56 2012
/dev/rdisk1s2: ** /dev/rdisk1s2 (NO WRITE)
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-557~393).
QUICKCHECK ONLY; FILESYSTEM CLEAN

ということで無事に復旧したようです。
で、ディスクに負荷をかけつつ半日ほど様子をみてましたが、最初に発生していた DISK I/O Error は出なくなっている風味なので、ホントに接触かなにかが原因だったのかもしれません…。まぁ今回は今のところ無事だったけど、バックアップは習慣づけてとるようにしましょうっていうありがちな教訓しか出てきませんね。
とりあえず保存できることが確認できて飽きていた Amazon Glacier への定期バックアップをちゃんと仕上げようとか心に誓いました(笑)

ちなみに disk1s2 I/O Error は、残ってるログを確認する限り、トラブルが起きた日だけ発生してた様子で、発生してから電プチするまでの約 4 時間で 84 件起きてました。ので、半日エラーが出てなけりゃしばらくは安心かなー、とか。あとログを冷静になって読んでみると

Oct 17 13:06:52 flora kernel[0]: jnl: disk1s2: do_jnl_io: strategy err 0x5
Oct 17 13:06:52 flora kernel[0]: jnl: disk1s2: write_journal_header: error writing the journal header!

と今回のトラブルを示唆するエラーが残されていたので、ここら辺を冷静に探れればもうちょっと早く対応出来たかなー、とか。

「Invalid content in journal」への2件の返信

コメントを残す