ファイルを消しても増えないディスク空き容量の怪
ファイルシステムの深淵を垣間見た。
とある日、サーバのディスク*1使用率をチェックしたところ、Availableなスペースが残り10%を切っていた。このパーティションは /usr で、メールを受け取る領域でもあるので、ここまでタイトな状況は好ましくない。そこで、当面いらなかったり既に不要となったファイルをごっそり消す。削除したファイルの合計は18Gぐらいはあった。が、空き容量がちっとも増えてない。増えていないわけじゃないが、18Gほどのファイルを消してディスクアクセスも収まっている*2にも関わらず 3G ほどしか増えていない。これはおかしい。きっと何かある。
念のため、durepで使用しているファイルシステムの分析をかけてみると、妙なことがわかる。当該パーティションの合計使用容量は、パーティションの半分ほどでしかなく、dfの表示と食い違っている。これはハードリンクなりスパースファイルなり、ディスク上の使用量とファイルシステム上の使用量が一致しなくなる何かが使われているときの典型的なパターンだ。
ありそうなのは、background fsckなりsoft-updateあたりが悪さしてること。このマシンにはFreeBSDがインストールされていて、問題のパーティションはsoft-updateが有効なUFS2パーティションだ。てことは、不意の電源断*3などで、ファイルシステムから外れているがfreeとマークされていないでかいファイルがあれば、その分で、ということはありそう。もしそうなら、現在background fsckが走っているはず。しかし、プロセスリストをみても fsck は走ってない。ついでにその電源断のときでも復帰前にきちんとシングルユーザーモードでfsckを行っている。なんてこったい。念のため、シングルユーザーモードでリブートをかけて fsck をかけても問題は検出されず、加えて空き容量も増えていない。
ここで durep コマンドでは、 .snap ディレクトリを対象外としていることを思い出した。dumpを -L オプションつきで実行しているので .snap にスナップショットファイルができるタイミングで durep をする*4と、重複してカウントされ当然アホな結果がでる*5ので、除外するよう設定していた。案の定調べると、アホのようにデカイサイズ*6の.usr/fsck_snapshot というスナップショットファイルがあった。
.snapにあるスナップショットファイルは、/devにあるデバイスファイルと同じようにシンボリックな存在で、こいつを消したからといって、ディスクの空き容量が80%にまで増えるわけではない。しかし、だ。現に見えているファイルシステム側（たとえば/usr/local/mokemoke/a)を消しても、スナップショットに含まれているならディスク空き容量が増えるわけがない。なぜなら、ハードリンクされているようなものだから。逆にスナップショットにしか含まれていないファイルについていえば、このスナップショットを消せば、その分のスペースは利用できるようになるはず。
とすると、このスナップショットを消せば問題は解決しそうな気がする。スナップショットファイルも、rmコマンドで使ってないなら安全に消せるよと書いてある。さらにシングルユーザーモードでfsckを走らせた後なら、使っているはずがなく、しかも安全なはず。というわけで、バックアップをちゃんととれていることを確認してから、このファイルを rm してみる。
...見事ディスクスペースが空いて、ファイルの合計使用量をパーティションの全容量から引いたサイズが、空きサイズとがほぼ一致するようになった。念のため、消した後にfsckをしてみるが、問題は検出されづ。やれやれ。
それにしても、なんでこのファイルが残っているのだろう？この fsck_snapshotは、background fsckが使うファイルなのはわかるし、background fsckが使用していないにも関わらず使用しているとマークされている領域を解放することもわかる。ってことはあれか。background fsckが走っているような状況でまたマシンが落ちた、とかなどの理由でスナップショットがずーっと残っていた、とかそういうシナリオっぽいな。
とりあえず解決してよかった。
