3

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

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

感谢您的专业知识！

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

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

4

3 回答 3

3

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

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

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

于 2011-02-02T20:13:50.490 回答
3

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

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

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

于 2011-02-02T20:16:43.233 回答
2

这两个选项都需要在目录 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 个文件是避免性能问题的合理限制。

于 2011-11-06T17:47:17.680 回答