對於區塊層級或更詳細的重複資料刪除有哪些可用的解決方案？
有基於文件的 - 採用“寫入時複製”方法。
我正在尋找區塊級“寫入時複製”，因此我可以定期查找公共區塊，或者最好是文件的一部分，合併它們並標記 CoW 使用方式。是否有類似的東西可用，或者仍然需要創建它？我不確定 Btrfs 重複資料刪除是否是區塊/檔案/子部分層級？有 LessFS，但我不確定它提供什麼級別的重複資料刪除？也許還有其他解決方案？
答案1
隨著區塊級重複資料刪除的發展，我認為 ZFS 是目前無可爭議的最佳實現。它確實不是為事後優化而設計的，因為它的重複資料刪除（如果開啟）直接內建在讀取/寫入功能中。因此，在嘗試將重複資料刪除表的最相關部分保留在內存中時，在負載下可能會佔用一些內存，但 ZFS 善於將自身限制為消耗不超過 50% 的內存，這取決於安裝的內存數量似乎相當任意（2Gb 的50% 與64Gb 的50%，特別是在需要記憶體的使用者任務很少（如果有的話）的情況下）。
根據您想要使用它的用途，您有一些選擇：
印第安納公開賽似乎有一些基於 Solaris 的不錯的桌面和伺服器選項
FreeBSD（自 9.0 起）內建了相當進階的 ZFS 版本（包括重複資料刪除）。一個值得注意的 FreeBSD（然後是 MonoWall）派生發行版是NAS4免費，這使得製作 NAS 變得非常容易。
Linux 有幾個選項，有些有重複資料刪除功能，有些則沒有。既然您正在尋找重複資料刪除，我見過的最值得注意的是zfsonlinux。我不確定他們的進展如何，或者他們的專案有多穩定，但它看起來絕對有希望。
至於任何具有部分區塊重複資料刪除功能的東西，到目前為止，我還沒有看到任何報告有能力做到這一點。
答案2
由於術語“塊”，您的問題有點令人困惑，當涉及磁碟和檔案系統時，這是一個非常重載的詞。 （但是您周圍的上下文有助於澄清。）Btrfs 不處理固定大小的檔案系統“區塊”，它處理可變大小的“範圍”。 （儘管令人困惑的是，它還定義了可變大小的區塊區域。）ZFS 處理檔案系統“區塊”，部分或主要是因為這樣做會更容易解決問題。 Btrfs 和 ZFS 都知道磁碟級“區塊”，它們本身就是抽象。 （然後我們還有“區塊級儲存”，這在語義上可能是不同的含義。）我的這些描述可能有點偏差，不夠清晰，或者不是 100% 準確。 （如果您需要關於區塊主題的清晰度和 100% 準確度，請假裝您沒有閱讀該內容。如果您只需要粗略的理解才能繼續，那麼您應該很好地繼續。）這個答案的要點不是完美定義“塊”，但下面的討論在我的駕駛室中更多。
正如 @killermist 所寫，ZFS 本身支援 [ZFS] 區塊級重複資料刪除。
ZFS 中預設未啟用它。在沒有足夠內存的情況下打開它會嚴重影響性能。此外，據傳，ZFS 需要比「每 1tb 儲存 1gb RAM」建議的經驗法則更多的數量，才能將整個哈希表放入 RAM。但即便如此，根據硬體的不同，您仍然可以獲得高達 40 MB/s 的寫入速度。我在運行 ~2015 時代驅動器的 2008 時代技術上得到了這一點。對於大部分檔案資料來說，我完全可以接受。 ZFS 重複資料刪除的最大缺點是，除了開啟重複資料刪除、將所有內容複製到相同檔案系統上的新暫存目錄，刪除原始目錄，然後將（現已刪除重複的）暫時內容移回原處。 （除了刪除舊檔案可能比初始複製/重複資料刪除操作花費更長的時間。）我通常所做的是等到我必須定期重新建構陣列以更改基本佈局，然後從舊陣列複製到新的，已啟用重複資料刪除。
Btrfs 重複資料刪除可以說有點粗略，目前只有第三方實用程式可以完成這項工作。 （但它們要么使用受良好支援的內核API，和/或受良好支援的cp 選項；並且無論哪種方式都需要它們自己的邏輯來確定重複項，人們希望這是完全準確的。）不過，一個潛在的好處是這些實用程式是「帶外」的。然而，大多數公用事業公司的成本是，他們在不斷敲擊的過程中犧牲了性能——這可能需要數小時、數天甚至數週才能完成。 （就我個人而言，我寧願處理帶內 ZFS 重複資料刪除的寫入效能始終較慢的情況，也不願連續數日錘擊我的 HDD，例如每年結束一次。）
我知道有兩個 Btrfs 解決方案處理“塊”（但在另一個定義中）而不是文件，它們是蜜蜂， 和杜普。
例如，蜜蜂在第一次運行時根據可用記憶體和可能的其他因素為自己任意定義「區塊」大小。 （雖然我可能歪曲了它的目的、特性、機制和優點/缺點，因為我不使用它，我最近才將它作為一種選擇進行評估。）
Bees 可以說是有點混合型，因為它被設計為連續運行，並且不會那麼用力地敲擊磁碟 - 儘管在技術上仍然不像 ZFS 重複資料刪除那樣「帶內」。它只是在事後拾取重複項，並嘗試輕輕一觸即可刪除重複項。使用任意定義的區塊大小意味著，根據設計，它將適合 RAM 中的雜湊表。缺點（大概）是「區塊」中可能存在相同的範圍，但 Bees 可能不會進行重複資料刪除，因為它們所在的「區塊」在其他方面是不同的。
請記住，即使是專門執行「檔案」等級 Btrfs 重複資料刪除的實用程式（例如寢具,杜佩刪除,林特等等），仍然可以滿足您的要求。我不能確定，但看起來他們會的。這是因為即使是「cp --reflink=always」指令也不能真正刪除「檔案」的重複資料。它正在對 Btrfs 進行重複資料刪除範圍。當重新連結的「檔案」發生變更時，Btrfs 僅將變更的範圍取消重複資料刪除到其自己的唯一範圍。文件的其餘部分仍然經過重複資料刪除。這就是大型的重複資料刪除檔案仍然可以像它們自己的獨特檔案一樣分散，但仍然大部分被重複資料刪除。
（這也是為什麼很難確定“文件”是否被重新鏈接，因為這個概念甚至沒有真正的意義。文件的所有內容範圍本身可能會被重新連結到其他相同的範圍，這個概念確實有意義，但巧合的是，這是一個特別難以回答的問題。這就是為什麼，除非 Btrfs 重複資料刪除實用程式追蹤它已經刪除重複的內容，否則不值得嘗試「偵測」檔案是否已刪除重複。沒有像引用計數這樣的屬性可供檢查。無論如何，再次刪除重複資料會更容易。相比之下，確定整個文件是否以老式方式硬連結是微不足道的。只需檢查給定 inode 的 st_nlink 計數。
事實上，缺乏「整個檔案克隆」是所有支援「免費」快照和/或重複資料刪除的 CoW 檔案系統的固有特徵，無論是處理 Btrfs 範圍、ZFS 區塊還是其他東西，都是如此。這就是為什麼其中任何一個都可以回答您的問題。 （據我所知，至少還有其他三個 CoW 檔案系統可以或計劃可以完成所有這些工作：nilfs2、bcachefs 和 xfs。）
儘管您沒有提到這一點，但據我所知，沒有重複資料刪除技術可以識別文件類型。換句話說，沒有重複資料刪除器知道跳過 *.jpg 元數據，只考慮壓縮影像資料進行重複資料刪除。同樣，他們都沒有考慮檔案幻數（至少在確定重複資料刪除時要考慮什麼）。這可能是個殺手級功能——儘管肯定需要不斷的、持續的定義更新。而且將檔案視為擴充區、區塊等的抽象 M:M 集合時，設計起來可能非常困難。