【问题标题】：Why doesn't "total" from ls -l add up to total file sizes listed? [closed]为什么 ls -l 中的“总计”不等于列出的总文件大小？ [关闭]
【发布时间】：2011-11-16 03:11:38
【问题描述】：

为什么ls -l 的输出中的total 打印为64 而不是26078，这是列出的所有文件的总数？

    $ ls -l ~/test/ls
    total 64
    -rw-r--r--   1 root root   15276 Oct  5  2004 a2ps.cfg
    -rw-r--r--   1 root root    2562 Oct  5  2004 a2ps-site.cfg
    drwxr-xr-x   4 root root    4096 Feb  2  2007 acpi
    -rw-r--r--   1 root root      48 Feb  8  2008 adjtime
    drwxr-xr-x   4 root root    4096 Feb  2  2007 alchemist

【问题讨论】：

@LIU Qingyuan 其次，这个q显示了界面中的多个故障。 1) -l 设置为以几乎没有人需要的神秘方式显示总数。但是-lh 是您 99.9% 的时间所需要的。那么为什么不在 MB 中创建 -l 并在块中创建 -lAlmostNeverNeeded 呢？ 2）--help 中没有总数 3）man 中没有总数 4）让我们提倡时间浪费：查看--help，转到man，记住info，阅读更多。（如果您使用的是 windows 便携式 bash 不包括 man 或 info，所以您需要像我现在一样使用谷歌搜索它。）最后，让我们惩罚本地人的问题。我们奖励无休止地阅读糟糕的手册。

标签： linux shell unix command prompt

【解决方案1】：

您可以在您的平台的ls 文档中找到该行的定义。对于coreutilsls（在很多Linux系统上都有），可以通过info coreutils ls找到信息：

对于列出的每个目录，在文件前加上一行 `total BLOCKS'，其中 BLOCKS 是所有磁盘的总分配该目录中的文件。

【讨论】：

有趣的是，我系统上的man ls 没有提到那行，但info coreutils ls 有。为什么man ls 和info coreutils ls 对同一命令有不同的信息？为什么ls 不只记录一次？对同一个命令有两个不同的文档似乎是为失败而准备的。
info coreutils 的文档通常比手册页更详细。这就是为什么他们在每个手册页的末尾都有一个注释，供您参考信息部分以获取更多详细信息。
啊。我执行了info ls，它给出了与info coreutils ls 相同的输出。参数coreutils 做了什么？
@Mat 我已经修改了这个问题，希望它可以重新打开。希望你能投票...

【解决方案2】：

公式：那个数是多少？

total int = 每个文件的 (physical_blocks_in_use) * physical_block_size/ls_block_size) 之和。

地点：

ls_block_size 是一个任意环境变量（通常为 512 或 1024 字节），可通过 --block-size=<int>ls 上的标志，POSIXLY_CORRECT=1 GNU 环境变量（获取 512 字节单位），或 -k 标志强制 1kB 单位。

physical_block_size 是内部块接口的操作系统相关值，它可能连接或不连接到底层硬件。该值通常为 512b 或 1k，但完全取决于操作系统。它可以通过stat 或fstat 上的%B 值显示。 请注意，此值（几乎总是）与现代存储设备上的物理块数无关。

为什么这么混乱？

这个数字与任何物理或有意义的指标完全分离。许多初级程序员没有使用file holes 或hard/sym links 的经验。此外，关于这个特定主题的可用文档几乎不存在。

术语“块大小”的脱节和含糊不清是由于许多不同的度量很容易混淆，以及围绕磁盘访问的相对较深的抽象级别。

冲突信息示例：`du`（或`ls -s`）与`stat`

在项目文件夹中运行 du * 会产生以下结果：（注意：ls -s 返回相同的结果。）

dactyl:~/p% du *
2       check.cc
2       check.h
1       DONE
3       Makefile
3       memory.cc
5       memory.h
26      p2
4       p2.cc
2       stack.cc
14      stack.h

总计：2+2+1+3+3+5+26+4+2+14 = 62块

然而，当我们运行stat 时，我们会看到一组不同的值。在同一目录中运行 stat 会产生：

dactyl:~/p% stat * --printf="%b\t(%B)\t%n: %s bytes\n"
3       (512)   check.cc: 221 bytes
3       (512)   check.h: 221 bytes
1       (512)   DONE: 0 bytes
5       (512)   Makefile: 980 bytes
6       (512)   memory.cc: 2069 bytes
10      (512)   memory.h: 4219 bytes
51      (512)   p2: 24884 bytes
8       (512)   p2.cc: 2586 bytes
3       (512)   stack.cc: 334 bytes
28      (512)   stack.h: 13028 bytes

总计： 3+3+1+5+6+10+51+8+3+28 = 118 块

注意：您可以使用命令stat * --printf="%b\t(%B)\t%n: %s bytes\n" > 输出（按顺序）块的数量，（以括号表示）这些块的大小块、文件名和大小（以字节为单位），如上所示。

有两个重要的要点：

stat 报告上面公式中使用的 physical_blocks_in_use 和 physical_block_size。请注意，这些是基于操作系统接口的值。
du 提供了普遍接受的物理磁盘利用率的相当准确的估计。

供参考，这里是上面目录的ls -l：

dactyl:~/p% ls -l
**total 59**
-rw-r--r--. 1 dhs217 grad   221 Oct 16  2013 check.cc
-rw-r--r--. 1 dhs217 grad   221 Oct 16  2013 check.h
-rw-r--r--. 1 dhs217 grad     0 Oct 16  2013 DONE
-rw-r--r--. 1 dhs217 grad   980 Oct 16  2013 Makefile
-rw-r--r--. 1 dhs217 grad  2069 Oct 16  2013 memory.cc
-rw-r--r--. 1 dhs217 grad  4219 Oct 16  2013 memory.h
-rwxr-xr-x. 1 dhs217 grad 24884 Oct 18  2013 p2
-rw-r--r--. 1 dhs217 grad  2586 Oct 16  2013 p2.cc
-rw-r--r--. 1 dhs217 grad   334 Oct 16  2013 stack.cc
-rw-r--r--. 1 dhs217 grad 13028 Oct 16  2013 stack.h

【讨论】：

【解决方案3】：

这是列出的文件使用的文件系统块的总数，包括间接块。如果您对相同的文件运行 ls -s 并将报告的数字相加，您将得到相同的数字。

【讨论】：

这根本不是真的。示例：/bin/ls -s -> total 15 2 filename 3 filename2 3 filename3 3 filename4 2 filename5 2 filename6 2 filename8 2 filename9
我不知道你在什么系统上，但对我来说，它是真的。示例：gist.github.com/rfjakob/200f6001bf91cf801891
@Jakob 发布了一个完整的答案，看看并告诉我是否可以解决问题。
这在适用于 Windows 的 Git bash 中并非如此。
我已经修改了这个问题，希望它可以重新打开。希望你能投票...

【解决方案4】：

顺便提一下 - 您可以使用 -h (ls -lh) 将其转换为人类可读的格式。

【讨论】：

不幸的是，它还将所有列出的行转换为人类可读的格式。

公式：那个数是多少？

为什么这么混乱？

冲突信息示例：du（或ls -s）与stat

冲突信息示例：`du`（或`ls -s`）与`stat`