Linuxのディスク。空いているはずなのに0

/下は本来5GBくらいは空いているはずではないかと思うのですが、dfでみると空きが0になってしまいます。

# df
ファイルシステム 1K-ブロック 使用 空き 使用% マウント位置
/dev/sda2 7637400 7637292 0 100% /
/dev/sda1 101086 20574 75293 22% /boot
none 1037388 0 1037388 0% /dev/shm
/dev/sdb 20642428 9190668 10403184 47% /home
/dev/sdc 15481840 6056152 8639256 42% /backup
192.168.1.100:/home/httpd
20642432 9172096 10421760 47% /mnt/192.168.1.100
//storage1/backup$ 2926654528 1877643692 1049010836 65% /mnt/storage1
//storage2/backup 1945310816 1782780424 162530392 92% /mnt/storage2

とすると　/の空きが0になっています。

# find / -type d -maxdepth 1 | awk '{res = system("du -shx "$1)
というコマンドで/以下のフォルダごとの容量を表示させると、下記のようになります。

find: warning: you have specified the -maxdepth option after a non-option argument -type, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments.

1.4G /
920M /usr
72K /dev
4.0K /net
4.0K /opt
15M /sbin
160M /var
12K /tmp
4.0K /.dev.static
8.0K /lib64
4.0K /srv
8.8G /home
255M /lib
5.0M /bin
du: `/proc/5261/task': そのようなファイルやディレクトリはありません
du: `/proc/5261/fd': そのようなファイルやディレクトリはありません
897M /proc
4.0K /media
20K /mnt
16K /lost+found
4.2M /root
0 /sys
4.0K /initrd
30M /etc
4.0K /misc
4.0K /selinux
15M /boot
5.8G /backup

/の下は、duの結果にあるような、トータル7637292の容量を消費しているよう状態に見えません。何が問題なのでしょうか。確認すべき点を教えてください。

No.4 回答者： yakan9 回答日時： 2010/11/28 11:31

もう一つミスを見つけてしまいました。

> a,bは、セクター単位だから、4KBの整数倍と思われます。

ファイルシステムがext3の場合、4KBではなく、512Bですね。
ごめんなさい。

この回答へのお礼

どうもありがとうございます。

お礼日時：2010/12/03 09:32

No.3 回答者： yakan9 回答日時： 2010/11/28 11:16

回答No.2で、少し訂正しておきます。

ファイル管理テーブルで、ファイル管理テーブルのひとつのセクタ内にデータが入るような小さなファイルであれば、
ファイル管理テーブルとデータ格納領域で、１セクターしか使用しない場合があることです。
すなわち、一ファイル、一セクターですむ場合があるということです。

下記が参考になるかもしれません。
http://wiki.bit-hive.com/linuxkernelmemo/pg/Ext2 …

この回答へのお礼

どうもありがとうございます。

お礼日時：2010/12/03 09:33

No.2 ベストアンサー 回答者： yakan9 回答日時： 2010/11/27 21:39

> 何が問題なのでしょうか。

確認すべき点を教えてください。
前回の質問にも記載しましたが、ファイルシステムの管理テーブルを調査されることです。

ファイルを管理する上で何が必要なのか、
それらを管理すべきテーブルは、フォルダ毎、ファイル毎、それらの上位でまとめられた管理テーブルと、
Tree構造で管理されます。
よって、これらの管理テーブルのロスをいかにして見出し、追加容量として見える形にしていくのかだと思います。

> /下は本来5GBくらいは空いているはずではないかと思うのですが
質問の容量をK単位のものと、M単位のものを加えた容量を計算され、K単位のものが、160KB、
M単位のものが、2,286.2MBと計算されたものと思われます。
この値を単純に、7.6GBと比べて5GBはどこへ行ったといわれているのだと思います。

前回と同様に、dfコマンドで、フォルダ毎、ファイル毎にコマントで、そこで発生した管理テーブルロスを加えていくことになると思います。
しかし、そんな操作は不可能に近いので、フォルダに対しての管理テーブル容量(a)、ファイルに対しての管理テーブル容量(b)を調査します。
システムの全フォルダ数　X a = フォルダに対する管理テーブル量
システムの全ファイル数　X b = ファイルに対する管理テーブル量

a,bは、セクター単位だから、4KBの整数倍と思われます。
例えば、aとbは、4KBという最少数と仮定してどの程度の管理テーブルが必要でしよう。
5GBを使うためには、1,250,000個のフォルダとファイルがあることになります。多分これよりは少ないと思われます。

ではその他に必要な領域はというと、
バットセクタの代替用領域、各フォルダの予備領域等です。

参考になるかどうかは分かりませんが、フォルダ毎、ファイル毎の管理項目の一覧が下記にあります。
ファイルシステムの違いはありますが大きな差はないと思われます。
http://jiten.biglobe.ne.jp/j/42/4e/a5/52136b4430 …

単純にファイルを格納するためだけではありません。
格納し、管理し、検索し、リンクの前と後ろのつながり、領域の使用、未使用、復旧のための情報等の管理テーブルを含むことを忘れてはなりません。

この回答へのお礼

こんなに丁寧にご説明いただきまして、どうもありがとうございます。
大変勉強になりました。

お礼日時：2010/12/03 09:35

No.1 回答者： superside0 回答日時： 2010/11/27 19:52

すでにファイルが存在しているディレクトリーに対してmountすると　、

既存のファイルが見えなくなり、du の対象外になってしまいます。

もしかして、そういった状態で、ディスクを消費しているが見えない状態になっているかもしれないので、
たとえば/homeとか/backupをumount してから、　そのフォルダーをduやlsしてみてはどうでしょう？

この回答へのお礼

どうもありがとうございます。

お礼日時：2010/12/03 09:33