今回の件の事前の概要は以下の通りです。
- /var 領域にマウントされている仮想ディスクの領域は11GB
- 使用量が80%を越えるとメールが送信できなくなる（452 4.3.1 insufficient system storage）
- アクセスログなどは他領域に移動、シンボリックリンクを設置済み。
そして関連するかどうか判らない条件として、
- TokyoTyrantをインストールして運用したところ、接続処理が捌けなくなりエラーログが肥大した。
- /var領域を圧迫したため、ログを他領域に移動、シンボリックリンクを設置。
というものがあります。
で、何が起きたかというと、本来3.7GBしかない領域に8.7GBのデータが存在すると判断され、「削除するものがないのに領域を圧迫する」という事態でした。なんじゃこりゃ。
まぁ普通の人はもう判っただろうとは思うのですが、もう少し書くと、duで該当領域の容量を調べるとこんな結果が出ます。
$ sudo du --si /var
（略）
3.7G /varつまり/var領域にあるファイルの総計は3.7GBと言うことになります。よね？
しかし、dfで調べてみるとこんな返答が…
11G 8.0G 1.7G 82% /var全部で11GBの容量のうち、8.0GBを使用中で使えるのは残り1.7GB、使用量は82%ということです。2つの結果に実に4.3GBもの差があり、片方は余裕なのに片方はぎりぎりダメで、もう既に削除するものがない一杯一杯な状況。これってもしかしてダメって事ですか、俺なんかやっちゃいましたか…とちょっと諦めかけましたが、こちらを流し読んでなぜそうなるのか掴めました。
Q1 このような事象が発生するにあたり考えられる原因
<<>> 2008/07/01 19:09:53
A1
findコマンドで抽出した値はファイルシステム上のファイルのサイズを合計したものですが、
df -vkコマンドのUsed欄の数値は使用中のデータブロックの合計サイズです。
ファイルシステムは、1 Byteのサイズのファイルであっても一つのデータブロック（4KBytes）を割り当てます。
つまり全てのファイルが正確にデータブロック（あるいはフラグメント）のサイズの倍数にでもならない限り、
df , ls -l 双方の数値は大幅に異なるのが通常です。
又、dfのUsed欄はファイルのデータ格納だけでなく、メタデータを格納するブロックの容量も含みますので、ls -l から抽出される数値と一致することはありません。
（中略）
さらに、df統計量は、プロセスによってアクセスされているファイルを削除しても、そのファイルがクローズされない限りはファイル削除による変更を反映しません。
IBM – dfコマンドの結果とlsコマンド結果のサイズ不整合についてなるほど…
さらに、df統計量は、プロセスによってアクセスされているファイルを削除しても、そのファイルがクローズされない限りはファイル削除による変更を反映しません。
ん？
そのファイルがクローズされない限りはファイル削除による変更を反映しません
…え、そうなの…？
つまりさ、例えばさ、TokyoTyrantがまだ動いてるのにそれを止めるのが嫌で、logファイルをmvして同時にln -sするようなことをしてファイルを退避させたりした場合、TokyoTyrantはファイルに絶賛アクセス中だから、dfの数字は減らないってことっすか…どうしてその数字を信用するかなぁ…（安定性のためには当然なんだけど）
というわけで、無言でTokyoTyrantを再起動。ついでにApacheも再起動。見事に数字が3.9GBまで減りまして（0.2GBずれてるけどよく分からんしもういい）、無事メール送信再開。
無知は社会的リスクですね…。実感しました。解決してホントに良かった…
