方法一：
du -lh --max-depth=1 /path
先在/path目录下找出最大的目录path1，然后再在path1下找出最大的目录，这样一级一级就可以找出占用空间最大的目录了
du -lh --max-depth=1 /path/path1
方法二：
du -sh /* 查看占用的大小，找到最大目录后继续往里找
运行 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%的情况了。
