问题阐明
IDC里的一台服务器的/分区使用率爆满了！已达到100%！经查看发现有个文件过大（80G），于是在跟无关共事确认后rm -f果决删除该文件。然而发现删除该文件后，/分区的磁盘空间压根没有释放出来，使用率还是100%！这是为什么呢？
[root@linux-node1 ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/mapper/VolGroup00-LogVol00 58G 7.8G 47G 100% /tmpfs 1.9G 0 1.9G 0% /dev/shm/dev/vda1 190M 72M 108M 40% /boot起因剖析：
在Linux零碎中，通过rm或者文件管理器删除文件，只是将它会从文件系统的目录构造上解除链接(unlink)，也就是说只是删除了文件和系统目录构造的链接；
如果文件在删除时是被关上的（有一个过程正在应用该文件，文件被过程锁定或者有过程始终在向这个文件写数据等）状态，那么过程将依然能够读取该文件，也就是说没有删除掉文件在读取的状态，所以磁盘空间也就会始终被占用。
一个文件在文件系统中的寄存分为两个局部：数据局部和指针局部，指针位于文件系统的meta-data中，数据被删除后，这个指针就从meta-data中革除了，而数据局部存储在磁盘中，数据对应的指针从meta-data中革除后。
文件数据局部占用的空间就能够被笼罩并写入新的内容，之所以呈现删除文件后，空间还没开释，就是因为有过程还在始终向这个文件写入内容，导致尽管删除了文件，但文件对应的指针局部因为过程锁定，并未从meta-data中革除，而因为指针并未被删除，那么零碎内核就认为文件并未被删除，因而通过df命令查问空间并未开释也就难能可贵了。
解决措施有以下几种
- 通过lsof|grep deleted命令获取到曾经被删除然而依然被应用程序占用的文件列表，而后kill掉还在占用所删除文件的过程。须要留神的是：如果有很多过程都在应用所删除文件，那么采纳第1种形式kill过程就有点麻烦了，而且危险也比拟大。
因为kill过程是通过截断proc文件系统中的文件能够强制要求零碎回收调配给正在应用的的文件。必须要确定不会对运行中的过程造成影响时能力应用，应用程序对这种形式反对的并不好，当一个正在应用的文件被截断可能会引发不可预知的问题。
- 或停掉或重启应用这个所删除文件的利用，让OS主动回收磁盘空间。
- 也能够重启操作系统，不过这并不是最好的办法
- 看待这种过程不停对文件写日志的操作，要开释文件占用的磁盘空间，最好的办法是在线清空这个文件。通过这种办法，磁盘空间岂但能够马上开释，也可保障过程持续向文件写入日志。
在线清空文件（比方/home/wangshibo.log）的形式：
a）# echo " " > /home/wangshibo.logb）# cat /dev/null > /home/wangshibo.logc）# > /home/wangshibo.log还有一种磁盘空间应用问题的景象：明明应用df -h命令查看磁盘空间使用率不算高，还有很多空余空间，然而创立文件或写入数据时始终报错磁盘写满：" no space left on device"！
个别这种问题都是因为分区目录下deleted删除后的资源空间没有真正释放出来导致的, 具体解决流程如下:
- 先df -lh查看一下磁盘应用情况, 发现/data分区下的Used已用空间很大, 然而理论查看并没有占用那么大的空间!
- 找到被删除文件所在的分区, 比方/data分区
- 查看被删除了的所有文件：lsof -n /data |grep deleted
- 杀死这些文件的delete过程, 开释空间: lsof -n /data |grep deleted|awk '{print $2}'|xargs kill -9
- 接着再运行lsof -n /data |grep delete，应该就没有后果了。
- 留神: 刚杀死deleted过程时, df -h查看/data 分区, Used已用空间可能时霎时显示过大, 但随着deleted过程杀死, 资源逐步开释, /data分区下的Used已用空间会逐步变小, Avail可用空间会逐步变大)
大多数文件系统都会保留一部分空间留作紧急情况时用（比方硬盘空间满了），这样能保障有些要害利用（比方数据库）在硬盘满的时候有点余地，不致于马上就 crash，给监控零碎和管理员一点工夫去觉察。不过有时候这部分预留的硬盘空间不必的话有点节约。
在Linux零碎中，ext2、ext3、ext4文件系统上通常会默认预留5％的磁盘空间，比方磁盘如果是2TB，这就意味着有100GB的空间会被预留下来，这样的话会不会显得有点节约了。能够通过"tune2fs"命令来扭转5％的默认设置，比方只预留2％的空间。然而不倡议设成0%，事实环境中这样做不平安。
[root@ss-server ~]# df -TFilesystem Type 1K-blocks Used Available Use% Mounted on/dev/vda1 ext4 41151808 4962148 34076228 13% /devtmpfs devtmpfs 1931468 0 1931468 0% /devtmpfs tmpfs 1941204 0 1941204 0% /dev/shmtmpfs tmpfs 1941204 652 1940552 1% /runtmpfs tmpfs 1941204 0 1941204 0% /sys/fs/cgrouptmpfs tmpfs 388244 0 388244 0% /run/user/0[root@ss-server ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 40G 4.8G 33G 13% /devtmpfs 1.9G 0 1.9G 0% /devtmpfs 1.9G 0 1.9G 0% /dev/shmtmpfs 1.9G 620K 1.9G 1% /runtmpfs 1.9G 0 1.9G 0% /sys/fs/cgrouptmpfs 380M 0 380M 0% /run/user/0比方下面"/"分区是ext4文件系统，默认零碎预留了5%也就是2G的空间。当初能够通过"tune2fs"命令将零碎预留空间改为2%。
[root@ss-server ~]# tune2fs -m 2 /dev/vda1tune2fs 1.42.9 (28-Dec-2013)Setting reserved blocks percentage to 2% (209704 blocks)执行后，发现"/"分区腾出了1G的空间，这时零碎预留空间也就是2%了。
[root@ss-server ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 40G 4.8G 34G 13% /devtmpfs 1.9G 0 1.9G 0% /devtmpfs 1.9G 0 1.9G 0% /dev/shmtmpfs 1.9G 620K 1.9G 1% /runtmpfs 1.9G 0 1.9G 0% /sys/fs/cgrouptmpfs 380M 0 380M 0% /run/user/0留神：Linux下只有ext2、ext3、ext4文件系统时，零碎才会默认预留5%的磁盘空间。如果文件系统是xfs、tmpfs、devtmpfs、overlay等，则零碎默认不会预留磁盘空间。
福利：豆花同学为大家精心整顿了一份对于linux和python的学习材料大合集！有须要的小伙伴们，关注豆花集体公众号：python头条！回复关键词“材料合集”即可收费支付！