HDDの空きがあるのに残料が0と表示される

質問

しばらく使いつづけていたLinuxで
表題のようなトラブルが発生してしまいました。

dfを実行すると
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda3 35G 33G 0 100% /
/dev/hda1 99M 54M 40M 58% /boot
の様な結果が出てしまいます。
明らかに/dev/hda3には空きがあり、
書き込みも可能です。
これが原因なのか、
postfix/cleanup[4730]: warning: C91F5ABAA8: write queue file: No space left on device
の様な問題が発生していて困っています。

これは設定か何かをいじって直せるようなものでしょうか?
HDDの故障にしては、
/dev/hda1が問題なく認識されているようなのですが…。

できるだけ再インストールなどは避けたいところです。

よろしくお願いします。

回答No.7

jgk · ベストアンサー

34534144÷36298348＝95.1%
ext2/3のデフォルトでrootに予約される領域は5%ですので、
ext2/3であるなら、やっぱり予約領域じゃないでしょうか？
tune2fsの-m (%指定)、-r (ブロック数指定)オプションで予約領域を変更できます。

前回食いつぶしたのってrootで食いつぶしたとか、
予約領域の無いファイルシステムを使っていたとかじゃないですかね？

お礼

ご回答ありがとうございます。

5%がrootの予約領域なのですね。
勉強になりました。
例にファイルを削除していったら
空き容量が認識されました。

回答No.6

vaidurya

で、みなさんは食い違いは発生していませんか?
ちょっと考えてたんだけど
hda1でも起きているという話を見て、よくあることなのだろうと思いました。
まぁ/bootでおかしなトラブルってそうそう無いでしょ?

実際、うちもおきているんですよね :-)
dh -hではなく、-hなしで見るとどうでしょう?
(aliasでdhがdh -hになっている可能性もあります)

たぶん、まるめ誤差ってことでいいと思います。

-hなしのブロック数でも誤差が出るのは
たぶん実ファイルサイズと(クラスタサイズに由来する)占有量の違いが積もり積もって…
残り容量は、常にdfでの総容量-使用量より小さいんだと思います。

で、0になっても書き込みができるのは
33Gの1%って、330MBもあるんですね。
ということは、165MB以下になれば、0Mになるのがdf -hの仕様なのだと思います。
-hなしだったら、0にならないんじゃないでしょうか?

小数点を含めた表示は、たぶん、df結果をスクリプト処理するとき厄介だから
dfはこの仕様でいいんだと思います。(kdfは小数点第一位まで出ます)

補足

ご回答ありがとうございます。

オプション無しのdfの結果が以下です。
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/hda3 36298348 34534144 0 100% /
/dev/hda1 101086 55225 40642 58% /boot

まるめ誤差……とかではなく、
使用可がはっきりと0になってしまっている状況です。

本当に空きを完全に食いつぶしてしまった事もあるのですが、
その時は当然ながら書き込みはできませんでした。
しかし、今回は書き込みなどの操作が行えてしまっているので
困っているところです。

回答No.5

Tacosan

「以前はこのような症状もなく」の「以前」とはいつのことでしょうか? 今回の状況と対比させるなら
「以前はサイズと使用量が等しいときにしか 100 % にならなかった, 設定を何も変えていないが今回になって突然サイズと使用料が異なるにもかかわらず 100 % になりかつディスクがいっぱいとみなされるようになった」
ということでないと無意味なのですが, それでよろしいでしょうか?
あと, 実は /dev/hda1 でも食い違いが生じているのですが, それには気づきませんか?
もう 1つついでにいうと, #3 がいっていることは「巨大なファイルをオープンしているプロセスがいたらどうしようもないのでそのプロセスを殺してファイルを消す」ということと同じですが, 認識できていますでしょうか.

補足

度々ありがとうございます。

「以前」というのは、おっしゃる通りの理解で問題ありません。

/dev/hda1の食い違いというのは54M + 40M で90Mにならないと
いうことでしょうか?
言われてみれば確かにその通りです。
これも同じ原因による可能性があるということでしょうか?

lsofの件ですが、
出力結果を眺めてみたところ、数百MB以上の大きさのファイルを
オープンしているプロセスは見付かりませんでした。
「プロセスがオープンしているファイルを消してもダメなので、
そうでないファイルを消せば多少なりとも空き容量が増えるはず」
と私は理解したのですが間違っていましたでしょうか?

回答No.4

Wr5

df -i
とやったらどうなりますかね？

補足

ご回答ありがとうございます。

df -iを実行してみました。
Filesystem Iノード I使用 I残り I使用% マウント位置
/dev/hda3 4611264 247601 4363663 6% /
/dev/hda1 26104 100 26004 1% /boot
iノードはまだあるので大丈夫…という判断で問題ないでしょうか?

回答No.3

uwi

プロセスがオープン中のファイルをrmなどで消しても、dfの使用率は変わりません。
lsof などでオープン中のファイルがないか調べてみてはどうでしょうか？

参考URL：

http://ja.wikipedia.org/wiki/Lsof

補足

ご回答ありがとうございます。

lsofというコマンドがあるとは知りませんでした。
勉強になりました。
しかし、
lsof | grep ファイル名
でオープンされていないファイルを選んで削除してみましたが、
相変わらずの症状でした。

回答No.2

nizyuuichi

スワップのパーティションが2G取ってるんじゃないの？

ってか
普通　物理的なHDDって気にしないもんだけどね

用意したスライスに対して
どのくらい使用しているかとか
余ってるかとかは気にするけど

補足

ご回答ありがとうございます。

スワップ領域ではないと思います。
/dev/hda2
をスワップに割り当てていますので。
また、以前は問題なく使えていたのが、
突然この様な症状が発生したため、
別の可能性ではないかと推測しています。

回答No.1

Tacosan

root の予約領域ってありませんでしたっけ?

補足

ご回答ありがとうございます。
rootの予約領域なるものがあるのですか?

しかし、以前はこのような症状もなく、
設定などを変更した覚えもなく、
突然この様な状態に陥ってしまったので、
予約領域的なものが原因ではないのではないかと推測しています。