May 01, 2008

fsck_hfs Invalid extent entry

サーバが昨日より故障していました。アクセスして戴いた皆様におかれましてはご不便をおかけしました、この度ようやく復活できたようです。

サーバはPowerMac G3(350MHz) + MacOSXの10.2.8で構成してあるのですが、そろそろHDDが寿命のようです、という事情は以前の記事等で察していただけるかと思います。早く新しいMacMiniサーバへ乗り換えたいのですが、なかなかまとまった時間(次のGW4連休がチャンスと睨んでいます)をとることができずに、ずるずる使い続けていました。そしてコトが起こったのです。

コトの発端はバージョン管理を行うCVS(Current Version System)をeclipse上からssh経由(extssh)で使っている際に発生しました。ssh経由での接続には成功するものの、ファイルの同期を行おうとすると、create_adm_p /tmp/cvs-serv(pid)/(dir) : File too large というエラーが表示されます。ディスクには余裕があったので、File too largeの部分に引っかかりながらも、サーバ側のcvsの動作を疑いました。サーバ側のcvsコマンドはソースよりコンパイルしてあったので、状況を追うのは簡単でした。ソースからcreate_adm_pをヒントにエラーの発生箇所を検索します。

調べた結果cvsの中でシステムコールであるmkdir関数を使用して/tmpに一時ディレクトリを作成しようとした際にエラーが起きたようです。ということでcvs自体は問題がないようです。加えて手動で/tmpの下にディレクトリを切ることはできたので、この時点ではファイルシステムが何となく怪しいという程度にしか状況を解析できませんでした。

一度この状況で放置をしていたのですが、さらに困ったことがおきました。scpで単純なファイルをコピーしようとすると、やはりFIle too largeと言われるようになりました。更にサーバにローカルログインしてファイルを作成しても同じ現象が発生します。この時点で完全にディスクが怪しいという確信を得られたので、ブートディスクのチェック fsck_hfs -fd / をしてみると、Invalid extent entryなるエラーが発生していました。どうやらファイルシステムが破壊されつつあるようです。

Appleの技術情報『ディスクユーティリティおよび fsck を使用して、起動時の問題を解決する、あるいはディスクをメインテナンスする 』によると、このような場合はセーフブートによる回復やシングルユーザモードでの回復処理の実行によって状況が打開されるとあります。しかしながら今回発生したInvalid extent entryのエラーは修復されませんでした。検索によれば、純正のコマンド(fsck_hfs)やツール(Disk First Aid)等で回復できない類のエラーもあり、その場合には市販のソフトを導入して解決することが可能であるという情報も見受けられました。

しかしながら市販のソフトを導入したところで回復する見込みが100%でないことを考えると、ここで頑張る価値はあると考えました。まずは詳細なエラー情報を入手するため、fsck_hfsコマンドに改造を施しました。fsck_hfsをビルドするのに必要となるソースをdarwin(MacOSXと共通なopen sourceの部分)の開発者サイトから入手します。目的のコードは10.2.8/diskdev_cmds-208.11.2になります。

入手したソースに対して適宜手を加え、Invalid extent entryを発生させている部分を絞り込みました。 fsck_hfs.tproj/dfalib/CatalogCheck.cにあるCheckFile関数内でCheckFileExtents関数からの返却値がエラー(405行目付近)となっているようです。どうやらファイルシステム内のファイルを管理しているテーブルで異常で発生しており、その問題箇所と関連するファイルの名前はCheckFile関数のローカル変数filenameをprintfで吐き出すことで得られました。

ここまでわかったので、ファイルシステムのテーブルを直接修正しようかとも考えましたが、とりあえずおとなしく当該ファイルをrmコマンドで削除してみました。するとfsck_hfsで別のエラーが確認されるも、技術情報に従ってシングルユーザモードで起動、fsck -rfd / を行うと今度は全てのエラーが修復されました。これで無事解決に至りました。

この問題を振り返ってみると、サーバのHDDにバットセクタが発生している可能性が高いのではないかと考えられます。特にファイルシステムのテーブル部分は頻繁にアクセスがかかるので数年間の負荷に耐え切れずに今回のようなエラーが発生したのではないでしょうか。いずれにしても、できる限り早く新サーバに乗り換えたほうが先進衛生上好ましいようです。

14:25 fenrir が投稿 : 固定リンク | | | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/635