创建/删除许多硬链接的缺点？答案

【问题标题】：Disadvantages to creating/removing many hard links?创建/删除许多硬链接的缺点？
【发布时间】：2011-02-02 20:02:17
【问题描述】：

我需要创建数百到数千个临时硬链接或符号链接，这些链接将在创建后不久被删除。出于我的目的，两种类型的链接都可以工作（即目标不是目录，它始终存在于同一个文件系统中）

据我了解，符号链接会创建一个包含原始文件路径的小文件。而硬链接创建对同一 inode 中数据的引用。因此，如果我要创建/删除数千个这样的链接，创建和删除数千个小文件（符号链接）或数千个这些引用（硬链接）会更好吗？似乎一个对硬盘驱动器征税（可能是碎片），而另一个可能对文件系统本身征税？ inode 引用存储在哪里。做这么多硬链接是否有损坏文件系统的风险？速度呢？

感谢您的专业知识！

这是一种解决方法，能够使用 ffmpeg 从目录中的任意图像子集编码电影。由于 ffmpeg 要求正确命名文件（例如 frame%04d.jpg），我意识到我可以创建指向文件子集的硬/符号链接，然后适当地命名链接。这避免了重命名原始文件并不得不实际复制数据。它效果很好，但需要反复创建和删除数千个链接。

我相信也可以解决这个问题： convert image sequence using ffmpeg

【问题讨论】：

标签： linux ffmpeg hyperlink symlink hardlink

【解决方案1】：

如果此活动破坏了您的文件系统，那么您的文件系统有问题，而不是您。文件系统通常非常可靠，所以不用担心。

这两个选项都需要在目录中添加一个条目。符号链接也需要创建一个文件。当您访问文件时，硬链接直接跳转到内容，而访问符号链接需要找到符号链接文件，读取它，找到包含内容的目录，找到内容所在的位置，然后访问它。因此，符号链接对文件系统的工作量更大。

但是与实际读取文件中的数据的工作相比，差异很小。因此，我不会担心它，只选择最能满足您所需语义的那个。

【讨论】：

【解决方案2】：

由于您不想为同一个文件创建数十万个，因此硬链接的性能略好。

但是，如果 /tmp 是 tmpfs，则 /tmp 中的符号链接的性能甚至更好。

哦，符号链接太小而不会导致碎片问题。

【讨论】：

请您链接到您的声明的来源？并不是我对这些主张提出异议，而是这样的链接会使您的回答更有帮助。谢谢:)
@sampablokuper：来源：kernel.org。我不知道从阅读它的材料。我通过为我的硕士论文开发一个文件系统来了解这些材料。
很好 :) 如果论文提出相同或等效的声明，您可以引用该论文。无论如何，谢谢。
@sampablokuper：我的论文不是关于性能的。但我知道文件系统在磁盘上的样子。对我来说，这个问题是计算写入块和读取块。

【解决方案3】：

这两个选项都需要在目录 inode 中添加一个文件条目，目录结构可能会通过分配新块而增长。

但是符号链接需要分配一个 inode 并且文件系统对 inode 有限制。您的数十万个符号链接可能会达到该限制，即使有千兆字节，您也可能会收到 “文件空间不足” 错误消息。

默认情况下，文件系统创建工具会根据物理分区大小选择最大inode数量。例如对于 Linux ext2/3/4，mkfs.ext3 使用 bytes-per-inode 比率，您可以在 /etc/mke2fs.conf 中找到。

对于现有的文件系统，这里有一个命令来获取有关 inode 的信息：

# dumpe2fs /dev/sda1 | grep -i inode | less

Inode count:              979200
Free inodes:              742304
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       441066
Journal backup:           inode blocks

作为结论，您应该首选硬链接，主要是为了消耗磁盘和内存中的资源（缓存中的 VFS 结构）。

另一个建议：不要在同一目录中创建太多文件，2'000 个文件是避免性能问题的合理限制。

【讨论】：