linux系统中用lseek（）生成的空洞文件有什么用？

空洞文件很有用的，看看迅雷下载的文件，在未下载完成时就已经占据了全部文件大小的空间，这时候就是空洞文件。下载时如果没有空洞文件，多线程下载时文件就都只能从一个地方写入，这就不是多线程了。如果有了空洞文件，可以从不同的地址写入，就完成了多线程的优势任务。

在开发过程中有时候需要为某个文件快速地分配固定大小的磁盘空间

（1）可以让文件尽可能的占用连续的磁盘扇区，减少后续写入和读取文件时的磁盘寻道开销；

（2）迅速占用磁盘空间，防止使用过程中所需空间不足。

（3）后面再追加数据的话，不会需要改变文件大小，所以后面将不涉及metadata的修改。

lseek（）系统调用

功能说明：

通过指定相对于开始位置、当前位置或末尾位置的字节数来重定位 curp，这取决于 lseek() 函数中指定的位置

函数原型：

#include <sys/types.h>

#include <unistd.h>

off_t lseek(int fd, off_t offset, int whence)

参数说明：

fd：文件描述符

offset：偏移量，该值可正可负，负值为向前移

whence：搜索的起始位置，有三个选项：

(1).SEEK_SET: 当前位置为文件的开头，新位置为偏移量大小

(2).SEEK_CUR: 当前位置为文件指针位置，新位置为当前位置加上偏移量大小

(3).SEEK_END: 当前位置为文件结尾，新位置为偏移量大小

返回值：文件新的偏移值

有关于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空间，说明消失的空间就是碎片空间，我看网上很多解决办法都一样，很少有因为碎片导致的，所以我将这次问题解决办法记录下来留给后面的人参考。

---