我需要创建数百到数千个临时硬链接或符号链接，这些链接将在创建后立即删除。为了我的目的，两种类型的链接都可以工作（即目标不是目录，它始终存在于同一文件系统中）
据我了解，符号链接会创建一个包含原始文件路径的小文件。而硬链接在同一个inode中创建对数据的引用。因此，如果我要创建/删除数千个这样的链接，那么最好是创建和删除数以千计的小文件（符号链接）还是成千上万的这些引用（硬链接）？似乎有人对硬盘征税（可能是碎片），而另一个可能对文件系统本身征税？存储的inode引用在哪里。通过制作这么多硬链接，我是否有冒险破坏文件系统的风险？速度怎么样？
感谢您的专业知识！
这可以使用ffmpeg从目录中的任意图像子集编码电影。由于ffmpeg要求文件正确命名（例如frame％04d.jpg），我意识到我可以创建指向文件子集的硬/ sym链接，并恰好命名链接。这避免了重命名原始文件并且必须实际复制数据。它工作得很好，但它需要重复创建和删除数千个链接。
我也相信这个问题的解决方案： convert image sequence using ffmpeg
答案 0 :(得分：3)
由于您没有尝试为同一个文件创建数十万个，因此硬链接的性能略有提升。
然而，如果/ tmp是tmpfs，/ tmp中的符号链接表现更好。
哦，符号链接太小，不会造成碎片问题。
答案 1 :(得分：3)
如果此活动破坏了您的文件系统，那么您的文件系统是错误的，而不是您。文件系统通常非常可靠，所以不用担心。
这两个选项都需要在目录中添加一个条目。符号链接也需要创建文件。当您访问文件时，硬链接直接跳转到内容，而访问符号链接需要查找符号链接文件，读取它，查找包含内容的目录，查找内容的位置，然后访问它。因此，符号链接更适用于文件系统。
但与实际读取文件中数据的工作相比，差异很小。因此我不会担心它，只要选择最适合你的语言，就可以了。
答案 2 :(得分：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个文件是合理的限制，以避免性能问题。