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

Question

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

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

感谢您的专业知识！

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

我相信也解决了这个问题： 使用 ffmpeg 转换图像序列

Answer 1

如果此活动破坏了您的文件系统，那么问题出在您的文件系统上，而不是您。文件系统通常非常可靠，因此不必担心。

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

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

Answer 2

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

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

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

Answer 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 个文件是避免性能问题的合理限制。