一個 Rsync 客戶端需要 10 多個小時
rsync 版本 3.1.3-6 協議版本 31 cifs-utils/stable 2:6.8-2 amb64 nfs-common/stable 1:1.3.4-2.5 Debian Linux 10 Buster FreeNAS 11.3-U3.2 (IxSystems FreeNAS Mini)
我使用小型虛擬 Debian Linux 伺服器備份我的一些遠端設施的場景。我使用了 Debian 伺服器——因為我無法讓 FreeNAS (FreeBSD) 毫不費力地持續掛載 cifs 共享，所以我對 Linux 有點熟悉，如果可以避免的話，我不喜歡在 FreeNAS 的引擎蓋下搞亂——但是我可以讓 Debain 一致且可靠地掛載 cifs，以及讓 NFS 掛載 FreeNAS 伺服器——幾個月來一直執行良好。所以我的小 Debian 備份伺服器是 FreeNAS 伺服器和我的客戶端電腦之間的過渡。
Debian - 啟動時掛載和 NFS 共享到 FreeNAS - 永久 - 沒有遇到問題。Debian - 每 6 小時執行一次小批量腳本以掛載目標客戶端 Windows PC，然後將其數據從已掛載的 cifs 共享同步到已掛載的 nfs 共享。
我在想這可能是問題 - 找到了使用者聲明的這篇文章
就 rsync 而言，您正在兩個本地文件樹之間進行複制，因此它禁用了大部分優化（包括它著名的 delta 算法）。
所以我的問題是，有沒有辦法強制優化，即使它們被認為是兩個本地文件系統？在那篇文章中，他們試圖刪除，我不是 - 我的全部內容是備份所有囤積的使用者。
您可以使用該標誌強制進行優化
--no-whole-file，但除了減慢傳輸過程之外，它幾乎不可能做任何事情。在您考慮此選項之前，請確保您使用的是
--archive(-a) 或--times(-t) 標誌，以便保留文件修改時間。結合文件大小，這將有助於rsync確定其“快速檢查”是否足以跳過文件而不是重新復製文件。這就是為什麼這
--no-whole-file是一個壞主意。delta 算法檢查文件的塊以查看需要傳輸的塊。對於一個小的改變，可能只需要改變一個塊，這可能非常有吸引力。但是，為了確定哪些塊已更改，必須完整讀取源文件和目標文件。當您有兩個不同的系統時，這可以使用兩個獨立的處理器/磁碟組合併行完成，並且無論如何都必須讀取源文件，因此唯一的目標是讀取目標系統上的目標文件。但是，當您有兩個本地文件系統時，仍然需要讀取這兩個文件，但是會出現處理器和磁碟爭用。
在最壞的情況下，這意味著要寫入一個更改的塊，必須從頭到尾讀取兩個文件。但是此時您還不如只讀取一個並寫入另一個，因為無論如何您仍然需要重寫部分或全部目標文件。