解决linux系统下分区文件占用总空间比实际分区总容量要小却提示磁盘空间已满的问题

今天遇到个怪问题，同事反应部署tomcat的分区/app无法上传文件，无论是用lrzsz还是xshell附属的xftp均无法上传文件到指定位置，经检查目录权限均允许写入，然后查看系统分区空间大小发现空间已满，如下图(请忽略下面乱码)

如图上逻辑卷/dev/mapper/vs_app-LV_app所挂载的/app目录显示94%已占用率（原本占用率100%满载，经手动删除一些文件后降到94%)，但是查看app目录下所占用的实际大小总量只有40G不到，于是觉得很奇怪，总空间145G还有100多G哪儿去了？该目录下也并没有硬链接，于是开始怀疑服务器硬盘，阵列故障等等原因，不过还是首先开始检查LVM逻辑卷配置情况：

过滤掉内存项ram，可看出，有三个系统物理卷/dev/sda3，/dev/sda4，/dev/sda5充当LVM中的物理卷，总大小为4TB左右，而/dev/vg_app/LV_app总大小为146.48GB，是LVM分割出来的其中一个逻辑卷，结合fdisk查看，其余物理卷sda1，sda2，sda6均处于正常状态。遂百度之，找到一篇文章，内容如下：

linux里的文件被删除后，空间没有被释放是因为在Linux系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被打开的(有一个进程正在使用)，那么进程将仍然可以读取该文件，磁盘空间也一直被占用。
解决方法：
1、先df -lh查看一下磁盘使用状况
2、找到被删除文件所在的分区,eg.opt分区
3、查看被删除了的所有文件：lsof -n /opt |grep deleted
 结果如下：[root@test app]# lsof -n /opt |grep delete
 sftp-serv  8195      root    5r   REG  104,6 8214888448 786452 /opt/software/resin-pro-3.1.10/log/jvm-app-a.log (deleted)
4、kill 8195
5、再运行lsof -n /opt |grep delete，应该没上面的结果了。
6、再运行df -lh看是不是空间已经释放了？

--------------------------------------------------原文分割线---------------------------------------------------------

如上文所述，目录/app下部署的tomcat里头每次运行时会产生日志/tomcat/logs/catalina.out，当分区容量满了之后无法继续写入，会导致tomcat运行异常，故需要定期清理日志文件（删除，压缩备份转移，日志滚动），结合同事所提供信息，得知曾对日志文件进行直接删除操作。于是利用上述命令lsof -n /app | grep delete 检查空间未被释放的文件并将该进程pid杀掉之后，分区空间大小恢复正常。经查问，问题原因是由于同事在对tomcat进行日志清理操作时未将tomcat服务停用所导致，所以一般情况下切忌在应用程序运行过程当中对其运行相关文件进行操作。