CentOS磁盘空间查看及空间满的处理
如果要查看磁盘还剩多少空间，当然是用df的命令了。
[root@localhost ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda2 14G 11G 2.6G 82% /
/dev/sda1 99M 14M 81M 14% /boot
tmpfs 442M 275M 168M 63% /dev/shm
/dev/mapper/vg_test-lv_test
24M 1.3M 21M 6% /mnt/lvm
[root@localhost ~]#
当然你可能并不关系磁盘还剩余多少空间，你是需要知道当前的文件夹下的磁盘使用情况：
[root@localhost ~]# du –max-depth=1 -h
24K ./.gnome www.2cto.com
8.0K ./.eggcups
8.0K ./.config
136K ./.gnome2
16K ./.chewing
8.0K ./.gnome2_private
8.0K ./.Trash
224K ./.gstreamer-0.10
28K ./Desktop
48K ./.nautilus
48K ./.metacity
240K ./.scim
3.4M ./.mozilla
1012K ./.kde
12K ./.superkaramba
40K ./.local
8.0K ./.qt
272K ./.gconf
32K ./.mcop
16K ./.redhat
1.7M ./.thumbnails
8.0K ./.gconfd
7.5M .
[root@localhost ~]#
看上面使用了du –max-depth=1 -h的命令来查找磁盘的使用情况，因为后面没有跟路径，它就默认是当前的路径。这个命令的-h参数是为了方便你读懂每个文件的大小，如果没有这个参数显示的文件大小就没有k,M,G等。执行命令后，前面n-1行的是该目录下每个文件夹的大小。最后一行显示的是该目录总的大小。
然后你会说不在乎该目录下每个文件的大小，你只想知道其中某一个文件（文件夹）的大小，那么有没有办法呢？当然你应该记得，我一直强调的，方法总比问题多，这儿也不例外。
请看下面的例子：
[root@localhost ~]# du -sh
7.5M . www.2cto.com
[root@localhost ~]#
聪明的你一定发现了这里显示的大小和上面最后一行的大小是一样的。这就是说这里显示的大小是该目录的总大小。
我知道你心里在冷笑，不是方法比问题多吗？这里说的也只有一个答案。当然，我不会让你失望的。另一个方法比较土，但是还是可以解决问题的。
[root@localhost ~]# du -h –max-depth=0
7.5M .
[root@localhost ~]#
我想告诉你的是man手册里面已经告诉了：–max-depth=0的功能和-s的功能是一样的。
当然你也可以通过sed打印最后du -h –max-depth=1一行来解决问题，但我并不推荐。
这里涉及到一个原则，尽量使用命令提供选项的原始功能。如果命令没有提供该功能，才需要我们自己使用grep,sed,awk来选取我们需要的行。
当然du命令后面可以跟文件路径，来查看指定路径的大小的。
[root@localhost ~]# du -sh /opt/oracle
5.6G /opt/oracle
[root@localhost ~]#
如果磁盘过大，那么查看文件大小就比较忙，请等一会，呵呵。
[转] http://www.2cto.com/os/201207/142116.html
http://www.cnblogs.com/longdouhzt/p/3177755.html
以下转自：http://www.cnblogs.com/starRebel/p/5897450.html
今天在运行R脚本的时候报了个错：Fatal error: cannot create ‘R_TempDir’。排除了是自己写的代码的问题，想着应该是某个没见过的原因，google之，发现网上的说法是/tmp文件夹占满了磁盘空间。
运行 df 命令：
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG00-LV01
50G 47G 16M 100% /
发现确实有个分区被占满了。。。
第一次碰到这种情况，继续google之，使用如下命令
du -sh /* | sort -nr
可以得到 / 目录下所有文件和目录的大小的排序结果。
从中找出最大的，在我的机器中/var文件占用了47个G的大小，应该就是它了，使用上面的命令继续追踪：
du -sh /var/* | sort -nr
du -sh /var/log/* | sort -nr
du -sh /var/log/httpd/* | sort -nr
一层一层往下追踪，最后发现是 httpd/目录下的ssl_error_log占据了超大磁盘空间，看了下文件内容，估计是某次链接导致了大量错误信息被一遍遍的循环写入。
不多想，直接把这文件删除。
运行 df -i:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/VG00-LV01
3276800 226882 3049918 7% /
tmpfs 4069835 7 4069828 1% /dev/shm
/dev/md0 51200 39 51161 1% /boot
/dev/mapper/VG00-LV02
56705024 11756 56693268 1% /opt
没有太大使用量，这是因为-i查看inode节点情况，和文件大小是不同概念。
再次运行df -h命令：
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG00-LV01
50G 47G 16M 100% /
仍然还是100%，明明已经删除了啊。。。 不解，继续google之。。
结论是“在Linux中，当我们使用rm在linux上删除了大文件，但是如果有进程打开了这个大文件，却没有关闭这个文件的句柄，那么linux内核还是不会释放这个文件的磁盘空间，最后造成磁盘空间占用100%，整个系统无法正常运行。这种情况下，通过df和du命令查找的磁盘空间，两者是无法匹配的，可能df显示磁盘100%，而du查找目录的磁盘容量占用却很小。”
找出文件使用者，kill掉：
lsof -n | grep deleted
找到使用ssl_error_log文件的进程，kill掉，然后再次df -h，发现已经没有100%的情况了。
处理完成~~
