报告文件大小差异背后的原因是什么？
[root@localhost]# ls -lah sendlog -rw-rw-r-- 1 mail mail 1.3T Aug 15 17:30 sendlog [root@localhost]# du -m sendlog 24M sendlog 这引起了我们的注意，当一个服务器的备份一直没有配额问题，所以这不仅是“ls”，看到这个错误的大小。
想到“稀疏文件”和“块分配”这样的术语，但我不确定为什么会发生这种情况，或者它背后的真正原因。 显然这两个命令检查大小的方式有所不同，我是否总是相信du？
仅供参考，这应该是一个非常标准的邮件日志文件。
值之间的差异如下。
从stat（2）手册中，
struct stat { // snip off_t st_size; /* total size, in bytes */ // snip blkcnt_t st_blocks; /* number of blocks allocated */ // snip };
st_blocks字段表示分配给文件的块数，512字节单位。 （这可能比st_size / 512小，例如，当文件有漏洞时。）
ls报告的大小是st_size ，du报告的大小是st_blocks * 512
du报告的值是文件系统/磁盘上文件使用的字节数，而ls报告的值是与文件系统/磁盘交互时文件的实际大小/长度。 （除了使用磁盘上的使用，杜也只计算hardlilnked文件一次）
哪个价值是“正确的”取决于上下文。 如果你在磁盘使用之后du是正确的，如果你想知道文件中有多less个字节，ls / st_size是正确的。
另外，你可以通过使用各种选项get ie du（–apparent-size）来使用st_size报告的大小，或者你可以得到ls（-s）来报告使用的块的数量。
你关于你的日志文件假设一个稀疏的文件的假设听起来似乎合理，但是，我不知道的原因。
就像Kjetil解释的那样，你有一个稀疏的文件。 除非实际写入这些块，否则文件内的空白数据块不会分配给磁盘。 如何在日志文件中发生这是一个谜。 你必须检查你的审计日志从上次sendlog有一个正确的大小，到它有这个巨大的漏洞的时间。 也许答案是在日志文件本身。
也许有人故意在你的系统中造成混乱。 或者是一些软件错误。
您可以轻松创build自己的TB级文件：
dd if=/dev/zero of='OMG_Thats_a_1_terabyte_file!!.dat' seek=1T bs=1 count=1
该文件将在任何当前的Linux版本中分配几千字节的磁盘空间，同时支持稀疏文件的文件系统。
您的备份解决scheme需要更换。 现在任何严重的备份系统都能有效地处理稀疏文件。 即使使用GNU tar的最简单的解决scheme也支持它（-S或–sparse选项）。
也许你的du不支持这么大的数字？
您的文件系统可能已损坏（或磁盘有一些物理问题）。 你应该尽快做fsck（在卸载的分区上），然后看看这些数字会发生什么。