实际情况：
测试环境与生产环境centos7服务器同时出现了该情况，即通过df -h与du -sh /*统计出的结果相差很大。
测试环境：
生产环境：
可以看到实际使用的磁盘量与df统计值都有很大的差异。直接导致的结果就是磁盘使用量会在未来的某一天达到100%，而实际已用的磁盘却很少，最终磁盘无法使用，必须重做系统才行······想想都可怕。
按照网上的绝大部分说法是，在日志文件正在被写入时，执行了删除文件操作，导致文件一直被占用，无法释放。可以通过lsof |grep deleted命令来查看是哪个进程占用的，然后kill掉该进程，文件所占用的资源就会被释放，磁盘空间也自然释放了。
如果像网上说的这么简单就好了，网上的都是人云亦云。我停掉了所有的应用，重启了服务器，通过lsof |grep deleted查看是没有任何内容的情况下，磁盘情况就是上面的那样。根本不像网上说的，还有应用占用着，释放了就可以了。啥也没有，就是统计结果不一样，咋整？都不知道从哪入手解决这个问题。
于是我开始寻求帮助，问牛逼的同事，问网课的老师，问技术群，结果都是无功而返。其实这个问题我已经遇到过几次了，一直都想排查出结果，但是每次都是花了很多时间，铩羽而归。这不，昨天又花了1天的时间，也还是没有解决这个问题，内心非常沮丧。
但是，一切都没有那么糟糕，昨晚我回家正是沮丧之时，我的一位开发同事联系我说原因找到了，是因为反复的删除文件导致的磁盘产生碎片，占用了磁盘空间所致，通过清理磁盘碎片的方式，就可以解决这个问题。听到这个好相信，我都兴奋的不行了。于是按他所说的，我上网找到了关于xfs文件系统碎片整理的文章，具体如下：
参考文章：
https://blog.csdn.net/scaleqiao/article/details/47122329
虽然这是2015年写的文章，但是真的解决了我本次遇到的问题。感谢本篇文章的作者！
大家在执行下面的命令之前，一定要确保备份了环境中的重要应用和数据，以防万一。确认无误后，再执行如下。
执行：
yum install xfsdump
yum install xfslibs-dev
yum install xfsprogs
查看/dev/sdc1的碎片情况：
xfs_db -c frag -r/dev/mapper/cl-root
返回结果：
[root@devhadoop228 /]# xfs_db -c frag -r
/dev/mapper/cl-root
actual 109661, ideal95641, fragmentation factor 12.78%
Note, this number islargely meaningless.
Files on this filesystemaverage 1.15 extents per file
可以看到，碎片占用率是12.78%
整理碎片：
xfs_fsr /dev/mapper/cl-root
再次统计，df -h与du -sh /*就一致了。本次是在另外一台遇到相同情况的服务器上做的试验，可以看到，两种统计方式统计结果相同了：
问题也就完美解决了，原来是磁盘碎片占用造成的df统计结果大。这才是问题的根本原因！！！
另外，也要真心的感谢我的同事，能换角度思考问题，既然不是lsof能解决的问题，就换角度想会不会是文件系统的问题，进而找到了解决的方案。这也是我要学习他的地方，我查了一天都没有查出来，他只查了一会，就能解决问题，也确实是厉害！
怎么样，我是不是众多解决方案中的一股清流！希望当各位朋友遇到跟我一样的情况下，可以看到我的这篇文章，并且通过上述方法真的能解决这个问题，也算是我没有白折腾，希望可以帮助到大家！！！
网友评论