我正在嘗試製作一些文件/目錄的原始副本，但在我所知道的幾種方法中，所有方法似乎都不是最佳的。
例如，btrfs 可以透過使用cp --reflink=auto快速產生檔案的牛副本。
我嘗試過的：
- 符號連結：不好。文件已重新命名，連結已損壞。
- 硬連結：更好，但仍然不好。對一個文件的更改將更改另一個文件，並且我不一定希望更改另一個文件。
- 建立資料集的快照，然後克隆快照：這可以工作，但效果不佳。通常，我並不是在尋找整個資料集的副本，也不是為了讓這些副本像另一個資料集一樣運作。然後是克隆/快照/原始之間的父/子關係，據我所知，即使不是不可能打破，也很難打破。
- 使用
zfs send/receive並啟用dedup，將資料集複製到新資料集：這避免了使用克隆的父/子關係，但仍然不必要地創建另一個資料集，並且仍然受到必須100% 讀取檔案所涉及的緩慢問題的困擾再次引用而不是寫入的區塊。 - 複製檔案並讓 dedup 完成其工作：這可行，但速度很慢，因為檔案必須 100% 讀取，然後再次引用區塊而不是寫入。
zfs 發送/接收以及物理複製或 rsync 的速度進一步惡化，因為大多數內容都是壓縮儲存的，並且必須在讀取期間解壓縮，然後在 dedup 啟動以引用重複區塊之前進行壓縮。
在我所有的研究中，我還沒有找到任何與 btrfs 中的 --reflink 的簡單性類似的東西。
那麼，有沒有辦法在 ZFS 中建立牛副本呢？或「物理」複製並讓重複資料刪除完成其工作是唯一真正的選擇？
答案1
我認為您上面描述的選項 3 可能是您的最佳選擇。您想要的最大問題是 ZFS 實際上只在資料集/快照層級處理這種寫入時複製。
我強烈建議避免使用重複資料刪除，除非您已確認它適用於您的特定環境。我個人的經驗是，重複資料刪除運作得很好，直到有一個使用者或虛擬機器儲存被移入，然後它就會掉下效能懸崖並導致很多問題。僅僅因為它看起來對前十個用戶運作良好，當您添加第十一個（或第十二個，或第十三個，或其他）時，您的機器可能會崩潰。如果您想走這條路，請絕對確保您有一個完全模仿您的生產環境的測試環境，並且它在該環境中運作良好。
回到選項 3，您需要設定一個特定的資料集來保存要以此方式管理的每個檔案系統樹。設定並初始填充後，拍攝快照（每個資料集一個，略有不同）並將其升級為克隆。永遠不要再接觸原始資料集。
是的，這個解決方案有問題。我並不是說它不會，但考慮到 ZFS 的限制，它仍然可能是最好的。我確實發現有人有效地使用克隆：http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html
我對 btrfs 不太熟悉，但如果它支援您想要的選項，您是否考慮過設定一個單獨的伺服器來支援這些資料集，並在該伺服器上使用 Linux 和 btrfs？
答案2
方案 5 是最好的方案。
對於選項 3 中的父/子資料集，您可以提升克隆，它將不再是克隆資料集的子項。它仍然不會用完額外的區塊。 編輯：請注意，這只會顛倒父/子關係，而不是破壞它。
關於壓縮/加密的內容以及減慢複製速度的說法，這是完全錯誤的。您的處理器比區塊裝置快得多（即使使用 SSD）。僅舉一些範例數字，假設讀取一個區塊需要 10 秒，但解壓縮它只需要 1 秒，解密它只需要 2 秒。區塊 1 在 10 秒內被讀取並傳送到 CPU。當磁碟開始讀取區塊 2 時，CPU 開始解壓縮和解密。同時，無論區塊是否被壓縮，磁碟都花了完全相同的時間來讀取這兩個區塊（20 秒）。
同樣，在寫入時，只有第一個區塊被延遲。 CPU 壓縮/加密區塊 1 並將其傳送到磁碟。當磁碟寫入區塊 1 時，CPU 將開始壓縮/加密後續區塊。 CPU 讀取區塊的速度比磁碟寫入區塊的速度快得多，因此這不是問題。 （是的，它比這更複雜，但這就是要點。）
很抱歉對您問題中的一個小問題的解釋過長，但我想澄清這種誤解。