rsync 許多具有長文件名的小文件佔用大量頻寬
我有一個文件儲存伺服器，它使用文件的 sha256 雜湊作為文件名以及文件副檔名將文件儲存在磁碟上，並且在三個級別的目錄中，例如，帶有 sha256 雜湊的 PDF 文件
AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A將儲存在這樣的子目錄中：
<root>/AA/BB/AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A.pdf文件將被添加到目錄結構中，但永遠不會被刪除或修改。
我使用每 10 分鐘執行一次的 cron 作業保存此文件結構的實時副本，該作業使用 rsync 將文件推送到遠端伺服器。由於文件一旦添加就永遠不會被刪除或更改，實際上它只發送新文件。
我發現 rsync 僅用於比較兩個目錄（即沒有更改）的頻寬約為 11 MB，並且隨著文件總數的增加（目前為 148 207）而增加。這是有道理的 - rsync 實際上必須將所有文件名的列表發送到遠端伺服器，以確定遠端伺服器上缺少哪些文件名。
所以我的問題是：**有沒有辦法減少使用的頻寬？**它不一定是基於 rsync 的解決方案，但它會更可取。我正在考慮將 rsync 查看的文件限制為僅最近修改的文件，即在上次同步後修改，但似乎不建議這樣做：rsync only files created or modified after a date and time
還有其他建議嗎？
在大多數情況下不推薦使用，但考慮到您的目標是減少差異計算頻寬，它是合適的。考慮以下腳本流：
- 觸摸一個文件作為你的“高桿”，這需要係統地命名，而不是覆蓋你的最後一個“高桿”，現在是你的“低桿”。該腳本將在這兩個文件日期之間使用 mtime 傳輸任何內容。請注意，您不得重命名或以其他方式更改這些文件上的日期戳。
- 使用 find with
-newer <lowbarfile> ! -newer <highbarfile>選擇要傳輸的文件，管道到 rsync 就像您的參考問題一樣。- 每週（或每晚），重新同步整個目錄以確保沒有遺漏任何內容。獲取以這種方式傳輸的文件的電子郵件日誌，以便您查看前面的步驟是否出現問題。
這不像 inotifywatch 那樣出色的解決方案，但它在 8000 個目錄之後也不會中斷，並且您的層次結構似乎使用多達 256+65536 個目錄。