jam*_*mie 5 hard-link disk-usage
首先，谢谢大家的回答。
因此，我再次重新运行测试以测试下面的答案，即目录/文件夹条目占用 4KB，这使我的数字出现偏差，因此这次将 20,000 个文件放在一个目录中，并对另一个目录执行 cp -al。结果非常不同，在去掉文件名的长度后，硬链接计算为每个硬链接大约 13 个字节，比 600 好得多。好的，那么为了完整起见，下面给出的答案是由于每个条目造成的对于占用 4KB 的目录/文件夹，我再次进行了测试，但这次我创建了数千个目录并在每个目录中放置了一个文件。数学运算后的结果（增加了高清空间/按文件数（忽略目录））每个文件几乎正好是 4KB，
所以我正在考虑实施 rsync/hardlink/snapshot 备份策略，并想知道硬链接占用了多少数据，就像它必须将额外链接的条目作为目录条目等放置。无论如何我似乎找不到关于此的任何信息，我想它取决于文件系统。我能找到的唯一信息是他们不占用空间的建议（可能意味着他们不占用文件内容的空间），他们占用的空间可以忽略不计，因为他们只需要几个字节来存储硬链接。
所以我拿了几个系统（一个是虚拟机，一个在真实硬件上）并以 root 身份在根目录中执行以下操作：
mkdir link
cp -al usr link
该usr目录有大约 54,000 个文件。硬盘上使用的空间增加了大约 34MB。所以每个硬链接大约有 600 个字节，还是我做错了什么？
我在两个系统上都使用 LVM，格式为 ext4。
文件名大小总共约为 1.5MB（我通过执行 ls -R 并将其重定向到文件来获得它）。
老实说，带有硬链接的 rsync 工作得很好，我计划将它用于几台工作服务器上的日常备份。我还认为在相当长的一段时间内制作这样的增量备份/快照会很容易。但是，十天后 30mb 为 300mb，依此类推。此外，如果实际文件数据/内容只发生了一些变化，比如几百 KB，那么每天存储 30+ MB 的硬链接似乎过多，但我同意你对现代磁盘大小的看法。只是我没有在任何地方看到这个硬链接大小，我认为我可能做错了什么。Linux 操作系统上的硬链接是否为 600 字节正常？
为了计算使用的空间，我df在cp -al.
cp -al usr link创建了一堆硬链接，但它也创建了一些目录。目录不能硬链接¹，因此它们被复制。
每个硬链接占用一个目录项的空间，该目录项至少需要存储文件名和inode号。每个目录占用一个目录条目的空间，加上一个用于其元数据的 inode。大多数文件系统，包括 ext2 系列，都单独计算 inode 空间。所有硬链接都在复制操作创建的目录中。所以你看到的空间实际上是/usr.
在大多数文件系统中，每个目录至少占据一个块。4kB 是 Linux 上的典型块大小。因此，您可以期望副本占用 4×（目录数）（以 kB 为单位），加上需要多个块的较大目录的一些更改。假设 4kB 块，您的副本创建了大约 8500 个块，这听起来对于/usr包含 54000 个文件的目录来说是正确的。
目录必须只有一个父目录。它们实际上确实有硬链接（或者至少看起来是这样，尽管现代文件系统倾向于不使用硬链接）：一个用于它们在父目录中的.条目，一个用于它们的条目，一个用于..每个子目录中的条目。但是您不能与它们建立其他硬链接。某些 Unix 变体允许 root 对某些文件系统上的目录进行硬链接，但存在创建无法删除的循环或无法访问的隐藏目录树的风险。