Stale file handle　－消せないディレクトリ－

とあるディレクトリで生じた悲劇

ある日の午後、職場のアプリエンジニアさんから『あの、commonというディレクトリを作ったんですが、見れなくて・・・』と連絡が入った。

口頭だとよくわからないので、sshログインして確かめてみた。すると・・・

( ﾟдﾟ) ・・・ (つд⊂)ｺﾞｼｺﾞｼ (；ﾟдﾟ) ・・ !?

iノードブロックが消えた・・・？

なんかよくわからないけど、パーミッションがないっぽい。全部『？』だよ。なんとなくだけど、inodeが見れてないのだと思った。かいつまんで言うと、Linux系のファイルシステムは、以下の三つの状態に分けて保持される。(かなり大雑把に言ってます。信じないでください)

ハードリンク – inode – 実体

で、所有者情報とかアクセス権とかが格納されてるのがinode。このinodeが見れてなくて全部『?』になっている様子。

アクセス権が『?』ということは、誰の操作も受け付けないということ。たとえばrootユーザーがrmコマンドでこのディレクトリを消そうとする。でも権限情報の入ったinodeがないから、kernelはこのディレクトリに権限のあるユーザーの命令か判断できない。よってこうなる。

誰の言うことも聞かない。まさに無敵。ラオウみたいだ。

これってStale NFS file handleと一緒だ

昔みたことがあるエラーで似たようなのがあった。NFSサーバー側のファイルが障害で消失して、NFSクライアント側からも当然消えるはず・・・なのにハードリンクだけ残ってしまった。ハードリンクの残骸は一切の操作を受け付けず、通常の方法では消せなかった。

うちの環境はNFSじゃなくてローカルなんだけどなあ。

解決法

結局そのときは『上位階層ごと再マウントしてファイルハンドルを再ネゴシエート』させたら消せた。ってことで今回も同じようにアンマウント→マウント。実行、確認、直った！

原因は不明

これが一番困るのだが、なんでinodeが消えたのかわからない。現象としては、たぶんStale NFS file handleと一緒だと思う。何らかのエラーによって、実体もinodeも消えてハードリンクの残骸だけ残ったと。

今回はサービスイン前だからよかったものの、稼働後はアンマウントなんてできないので本当に恐ろしい。