你可以这么做，空洞不是自己造成的吗，你可以计算出空洞的位置，然后同样lseek将文件

描叙符移到空洞后，前提是你知道空洞在什么位置，不知道也行，判断'\0'的个数，连续出现则说明到了空洞的位置，然后将文件描叙符置于此，读出文件大小

有关于du和df的统计原理不熟悉的可以看一下我写的另外一片文章，这里不做过多介绍

在前天我遇到一个很奇怪的现象，一块板子上根目录df -h 查看使用率100%，使用大小34G，而du显示只有24G，消失了10G，首先想到的是删除了大文件，然后还有进程在使用这个文件，lsof |grep delete 这条命令就可以查出 将进程号kill 掉就可以了，但是这是最普通最常见的错误，很不幸，我的机器不是这个问题，因为我重启过两三次磁盘大小依旧没有变化，然后我查看了一下根目录下面是否有隐藏文件，以及是否有连接到其他分区的大文件的链接，经过排查都没有。

然后在高人的指点下，说有一种叫做空洞文件的东西，具体就是ll -h 和du -sh 显示是不一样的

大家可以自己测试生成空洞文件具体使用 dd if=/dev/urandom of=testfile bs=1M seek=999 count=1024  大家用ll -h 看到 大概2G du -sh 大概1G 看起来是有很大差距 ，但是我找遍了整个目录还是没有发现，存在空洞文件。

后来我试着往根目录下写100M数据发现根本写不进去，说明磁盘空间确实不大了并没有虚高，在跟使用者了解情况之后，无意间听到他说之前这上面反复删除过大量文件，我从这方面入手，想到是否是文件磁盘碎片

的问题，首先确保xfsdump，xfslibs-dev，xfsprogs安装成功，之后执行xfs_db -c frag -r /dev/mapper/root 检查碎片的情况，我查找大概有百分之八左右，按照估算才3G左右的碎片，但是当时没有剩余空间可用，抱着死马当做活马医，先让板子能用， 注意执行整理命令要先把数据进行备份，否则可能会造成数据丢失。整理碎片 xfs_fsr /dev/mapper/root 奇迹发生了，大概清理出来9.7G空间，说明消失的空间就是碎片空间，我看网上很多解决办法都一样，很少有因为碎片导致的，所以我将这次问题解决办法记录下来留给后面的人参考。

ll -h xxx 和 du -sh xxx文件大小不一致：

---

因为xxx是服务启动时使用 >生成的，在true进行清理时会导致文件空洞，在启动服务时使用 >>进行生成，避免此类问题。