硬連結似乎僅用於連結本身（不是文件數據）就需要數百個字節
附加資訊
首先，謝謝大家的回答。
因此，我再次重新執行測試以測試下面的答案，即目錄/文件夾條目佔用 4KB，這使我的數字出現偏差，因此這次將 20,000 個文件放在一個目錄中，並對另一個目錄執行 cp -al。結果非常不同，在去掉文件名的長度後，硬連結計算為每個硬連結大約 13 個字節，比 600 好得多。好吧，那麼為了完整性，下面給出的答案是由於每個條目對於佔用 4KB 的目錄/文件夾，我再次進行了測試，但這次我創建了數千個目錄並在每個目錄中放置了一個文件。數學運算後的結果（在 hd / 文件數量（忽略目錄）上佔用的空間增加）幾乎是每個文件的 4KB，
所以我正在考慮實施 rsync / hardlink /snapshot 備份策略，並且想知道硬連結佔用了多少數據，比如它必須將額外連結的條目作為目錄條目等。無論如何我似乎找不到關於此的任何資訊，我猜它取決於文件系統。我能找到的唯一資訊是他們不佔用空間的建議（可能意味著他們不佔用文件內容的空間），他們佔用的空間可以忽略不計，因為他們只需要幾個字節來儲存硬連結。
所以我拿了幾個系統（一個是虛擬機，一個在真實硬體上），並在根目錄中以 root 身份執行以下操作：
mkdir link cp -al usr link該
usr目錄有大約 54,000 個文件。高畫質使用的空間增加了大約 34MB。因此，每個硬連結大約需要 600 個字節，還是我做錯了什麼？我在兩個系統上都使用 LVM，格式為 ext4。
文件名大小總共約為 1.5MB（我通過執行 ls -R 並將其重定向到文件來獲得）。
老實說，帶有硬連結的 rsync 工作得非常好，我計劃用它在幾個工作伺服器上進行日常備份。我還認為在相當長的一段時間內進行這樣的增量備份/快照會很容易。但是，十天后 30mb 是 300mb 等等。此外，如果實際文件數據/內容只有少量更改，比如幾百 KB，那麼每天儲存 30+ MB 的硬連結似乎過多，但我同意你對現代磁碟大小的看法。只是我沒有在任何地方看到我認為我可能做錯了什麼的地方提到了這個硬連結大小。Linux 作業系統上的硬連結 600 字節正常嗎？
為了計算使用的空間，我
df在cp -al.
cp -al usr link創建了一堆硬連結，但它也創建了一些目錄。目錄不能硬連結¹，因此它們被複製。每個硬連結佔用一個目錄條目的空間，其中至少需要儲存文件名和inode號。每個目錄佔用一個目錄條目的空間，加上一個用於其元數據的 inode。大多數文件系統，包括 ext2 系列，都單獨計算 inode 空間。所有硬連結都在複製操作創建的目錄中。所以你看到的空間實際上是
/usr.在大多數文件系統中，每個目錄至少佔用一個塊。4kB 是 Linux 上的典型塊大小。因此，您可以期望副本佔用 4×（目錄數）（以 kB 為單位），加上需要多個塊的較大目錄的一些更改。假設 4kB 塊，您的副本創建了大約 8500 個塊，這對於
/usr包含 54000 個文件的目錄來說聽起來很合適。目錄必須只有一個父目錄。它們實際上確實有硬連結（或者至少看起來是這樣，儘管現代文件系統在底層往往不使用硬連結）：一個用於它們在父目錄中的條目，一個用於它們的
.條目，一個用於..每個子目錄中的條目。但是您不能對它們進行其他硬連結。一些 Unix 變體允許 root 對某些文件系統上的目錄進行硬連結，但存在創建無法刪除的循環或無法訪問的隱藏目錄樹的風險。