为了自己看的更清楚，也为了不断的总结，每次更新后都会另发一篇。
工作中遇到某一文件夹磁盘空间不够，当然每次都是清理日志，最后发现还是不太行，还不能扩容，只能先想办法迁移目录，避免此问题发生，但在这之前我选择了另一种办法，把预留空间再次减少，当然这个是最直接的办法，一般Linux系统默认会有5%的空间，以防止报警或者极端情况下不影响应用程序的运行。接下来是操作
先查看磁盘空间：df -h才看目录在系统的位置
CC180824S02P:~ # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 80K 3.9G 1% /dev/shm
tmpfs 3.9G 395M 3.5G 11% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/system-root 11G 4.4G 5.8G 44% /
/dev/sda1 485M 113M 347M 25% /boot
/dev/mapper/appvg-app 59G 1016M 55G 2% /app
/dev/mapper/system-usrlocal 4.8G 11M 4.6G 1% /usr/local
/dev/mapper/system-srv 4.8G 11M 4.6G 1% /srv
/dev/mapper/system-home 4.8G 1.7G 2.9G 37% /home
/dev/mapper/system-tmp 4.8G 481M 4.1G 11% /tmp
/dev/mapper/system-var 4.8G 315M 4.3G 7% /var
/dev/mapper/system-opt 4.8G 3.8G 795M 83% /opt
tmpfs 780M 20K 780M 1% /run/user/483
tmpfs 780M 0 780M 0% /run/user/1000
tmpfs 780M 0 780M 0% /run/user/0
我要选择的是/opt 接下来执行
CC180824S02P:~ # tune2fs -m 2 /dev/mapper/system-opt
tune2fs 1.42.11 (09-Jul-2014)
Setting reserved blocks percentage to 2% (26214 blocks)
再次查看发现减少了，我这里预留变为2%，当然0我们是不推荐的。
CC180824S02P:~ # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 80K 3.9G 1% /dev/shm
tmpfs 3.9G 395M 3.5G 11% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/system-root 11G 4.4G 5.8G 44% /
/dev/sda1 485M 113M 347M 25% /boot
/dev/mapper/appvg-app 59G 1016M 55G 2% /app
/dev/mapper/system-usrlocal 4.8G 11M 4.6G 1% /usr/local
/dev/mapper/system-srv 4.8G 11M 4.6G 1% /srv
/dev/mapper/system-home 4.8G 1.7G 2.9G 37% /home
/dev/mapper/system-tmp 4.8G 481M 4.1G 11% /tmp
/dev/mapper/system-var 4.8G 315M 4.3G 7% /var
/dev/mapper/system-opt 4.8G 3.8G 948M 81% /opt
tmpfs 780M 20K 780M 1% /run/user/483
tmpfs 780M 0 780M 0% /run/user/1000
tmpfs 780M 0 780M 0% /run/user/0
Linux磁盘空间被未知资源耗尽
在linux中，当我们使用rm在linux上删除了大文件，但是如果有进程打开了这个大文件，却没有关闭这个文件的句柄，那么linux内核还是不会释放这个文件的磁盘空间，最后造成磁盘空间占用100%，整个系统无法正常运行。这种情况下，通过df和du命令查找的磁盘空间，两者是无法匹配的，可能df显示磁盘100%，而du查找目录的磁盘容量占用却很小。
遇到这种情况，基本可以断定是某些大文件被某些程序占用了，并且这些大文件已经被删除了，但是对应的文件句柄没有被某些程序关闭，造成内核无法回收这些文件占用的空间。
那么，如何查找那些文件被某些程序占用呢，命令如下
lsof -n | grep deleted
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
dd 31708 higkoo 1w REG 8,2 5523705856 429590 /data/filetest (deleted)
命令打lsof -n | grep deleted印出所有针对已删除文件的读写操作，这类操作是无效的，也正是磁盘空间莫名消失的根本原因
之后用kill -9 pid删除进程即可释放空间
CC180824S02P:~ # lsof -n |grep deleted
nscd 1381 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1392 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1392 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1393 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1393 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1394 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1394 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1395 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1395 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1396 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1396 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1397 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1397 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1398 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1398 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1399 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1399 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1400 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1400 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1401 nscd 10u REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
nscd 1381 1401 nscd 11r REG 0,20 217032 17665 /run/nscd/dbjC6wwK (deleted)
CC180824S02P:~ # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 80K 3.9G 1% /dev/shm
tmpfs 3.9G 402M 3.5G 11% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/system-root 11G 4.4G 5.8G 44% /
/dev/sda1 485M 113M 347M 25% /boot
/dev/mapper/appvg-app 59G 1016M 55G 2% /app
/dev/mapper/system-usrlocal 4.8G 11M 4.6G 1% /usr/local
/dev/mapper/system-srv 4.8G 11M 4.6G 1% /srv
/dev/mapper/system-home 4.8G 1.7G 2.9G 37% /home
/dev/mapper/system-tmp 4.8G 481M 4.1G 11% /tmp
/dev/mapper/system-var 4.8G 316M 4.3G 7% /var
/dev/mapper/system-opt 4.8G 1.1G 3.7G 23% /opt
tmpfs 780M 20K 780M 1% /run/user/483
tmpfs 780M 0 780M 0% /run/user/1000
tmpfs 780M 0 780M 0% /run/user/0
运维就是不断的排错，找到问题最终解决问题。
补充：
lsof `which httpd` //那个进程在使用apache的可执行文件 lsof /etc/passwd //那个进程在占用/etc/passwd lsof /dev/hda6 //那个进程在占用hda6 lsof /dev/cdrom //那个进程在占用光驱 lsof -c sendmail //查看sendmail进程的文件使用情况 lsof -c courier -u ^zahn //显示出那些文件被以courier打头的进程打开，但是并不属于用户zahn lsof -p 30297 //显示那些文件被pid为30297的进程打开 lsof -D /tmp 显示所有在/tmp文件夹中打开的instance和文件的进程。但是symbol文件并不在列 lsof -u1000 //查看uid是100的用户的进程的文件使用情况 lsof -utony //查看用户tony的进程的文件使用情况 lsof -u^tony //查看不是用户tony的进程的文件使用情况(^是取反的意思) lsof -i //显示所有打开的端口 lsof -i:80 //显示所有打开80端口的进程 lsof -i -U //显示所有打开的端口和UNIX domain文件 lsof -i UDP@[url]www.akadia.com:123 //显示那些进程打开了到www.akadia.com的UDP的123(ntp)端口的链接 lsof -i tcp@ohaha.ks.edu.tw:ftp -r //不断查看目前ftp连接的情况(-r，lsof会永远不断的执行，直到收到中断信号,+r，lsof会一直执行，直到没有档案被显示,缺省是15s刷新) lsof -i tcp@ohaha.ks.edu.tw:ftp -n //lsof -n 不将IP转换为hostname，缺省是不加上-n参数
之前遇到的场景是同事删除了mysql的表，但是是在shell上执行rm表的文件，而不是通过drop table之类的命令去删除表的，于是mysql会一直占用这些表文件的句柄，最后造成磁盘空间100%，这种情况下，也不用重启mysql，只要进入mysql客户端执行flush tables就行了