創建/刪除多個硬鏈接的缺點？

Question

我需要創建幾百到幾千個臨時硬盤或符號鏈接，這些鏈接將在創建後立即刪除。爲我的目的，這兩種類型的鏈接將工作（即目標不是目錄，它始終存在於同一個文件系統）

據我瞭解，符號鏈接創建一個小文件，其中包含原始文件的路徑。硬鏈接創建對同一個inode中的數據的引用。所以也許如果我要創建/刪除成千上萬的這些鏈接，創建和刪除數以千計的小文件（符號鏈接）還是成千上萬的這些引用（硬鏈接）會更好？看起來像一個稅收硬盤驅動器（可能是碎片），而另一個可能會對文件系統本身稅收？ inode引用存儲在哪裏。我是否會通過創建如此多的硬鏈接來破壞文件系統？速度怎麼樣？

感謝您的專業知識！

這是一個解決方法，可以使用ffmpeg從目錄中的任意圖像子集中編碼電影。由於ffmpeg要求文件被正確命名（例如frame％04d.jpg），我意識到我只需創建指向文件子集的hard/sym鏈接，並恰當地命名鏈接即可。這避免了重命名原始文件並且不得不實際複製數據。它工作的很好，但它需要反覆創建和刪除成千上萬的鏈接。

排序地址的這個問題太相信： convert image sequence using ffmpeg

Answer 1

如果此活動破壞您的文件系統，那麼您的文件系統出現故障，而不是您。文件系統通常非常可靠，所以不用擔心。

這兩個選項都需要在目錄中添加一個條目。符號鏈接也需要創建一個文件。訪問文件時，硬鏈接直接跳轉到內容，而訪問符號鏈接需要找到符號鏈接文件，讀取它，找到包含內容的目錄，找到內容的位置，然後訪問它。因此符號鏈接對於文件系統來說是更多的工作。

但是，與實際讀取文件中的數據的工作相比，差別很小。因此，我不會擔心它，只要用最好的方式給你提供你想要的語義。

Answer 2

既然你是不是想創造數十萬個到同一個文件，硬鏈接是稍好一點的表演。

但是，/ tmp if/tmp中的符號鏈接是tmpfs的性能更好。

哦，符號鏈接太小，導致碎片問題。

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文件是一個合理的限制，以避免出現性能問題。