主页 / server / 问题 / 64052
Accepted
Coops
Asked: 2009-09-11 00:49:19 +0800 CST

文件大小不匹配

  • 772

报告的文件大小不同的原因是什么？

[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 是对的吗？

仅供参考，这应该是一个非常标准的邮件日志文件。

linux

4 个回答

  1. Best Answer

    值之间的差异如下。

    来自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 报告的值是与文件交互时的实际大小/长度。（除了在磁盘上使用，du 也只计算一次硬链接文件）

    哪个值是“正确的”取决于上下文。如果您在磁盘使用 du 正确之后，如果您想知道文件中有多少字节，则 ls/st_size是正确的。

    此外，您可以通过使用各种选项获取 ie du (--apparent-size) 来使用所报告的大小，st_size或者您可以获取 ls (-s) 来报告使用的块数。

    你关于你的日志文件是一个稀疏文件的假设听起来很合理，但是，我不知道的原因。

    • 10

  2. 正如 Kjetil 解释的那样，您有一个稀疏文件。在您实际写入这些块之前，文件内的空白数据块不会分配到磁盘。这是如何在日志文件中发生的是一个谜。您必须检查您的审计日志，从上次 sendlog 的大小正确到出现这个大漏洞的时间。也许答案就在日志文件本身中。

    也许有人故意这样做是为了对您的系统造成严重破坏。或者是一些软件错误。

    您可以通过以下方式轻松创建自己的 TB 级文件：

    dd if=/dev/zero of='OMG_Thats_a_1_terabyte_file!!.dat' seek=1T bs=1 count=1

    在具有支持稀疏文件的文件系统的任何当前 Linux 版本中，该文件将仅分配几千字节的磁盘空间。

    您的备份解决方案需要更换。现在任何严肃的备份系统都能有效地处理稀疏文件。即使是使用 GNU tar 的最简单的解决方案也支持它（-S 或 --sparse 选项）。

    • 3

  3. 也许你du不支持这么大的数字？

    • 0

  4. 您的文件系统可能已损坏（或磁盘存在一些物理问题）。您应该尽快执行 fsck（在未挂载的分区上），然后看看这些数字会发生什么。

    • 0

相关问题