我正在考慮 FreeNAS；並想事先確認我對其中的儲存可以/不能做什麼的理解是正確的。
初步建置：1 個儲存池，其中 2 個 6TB 硬碟相互鏡像；總有效容量為 6TB（忽略舍入和開銷）。
第一次擴充（2.5 - 3 年）：為伺服器新增 2 個 12TB 硬碟。將它們配置為第二鏡像對，並將它們新增至現有儲存池中；將我的可用儲存空間增加到 18TB。
第二次擴充階段 1（5.5 - 7.5 年）：為伺服器新增 2 個 24TB 硬碟。將它們配置為鏡像對，並將它們新增至現有儲存池中；將我的可用儲存空間增加到 42TB。
第二次擴展階段 2（緊接階段 1 之後）：重新平衡 6TB 驅動器上的所有數據，將其從池中刪除，然後從伺服器中物理刪除。剩餘可用儲存空間 36TB。
我的想法是：
每隔不到 3 年，所需的儲存容量就會翻一番，這是我從 2008 年至今使用 WHS 伺服器的經驗的延續。
在添加24 TB 硬碟後，6 TB 硬碟僅提供總儲存量的一小部分（1/7），並且已經足夠舊，如果我將它們保留在其中，可靠性將成為更重要的問題（浴缸曲線的錯誤一側） 。如果它們倖存下來，按照我的成長速度，我需要購買 48TB 硬碟的時間只會延長半年多一點；所以他們不會給我太多時間。
將自己限制為 4 個驅動器，讓我可以為我的 nas 使用緊湊型 mini-ITX 外形規格。超出這個範圍意味著更大、更昂貴的設定。 （在一兩天的過渡時間內，可以將 2 個驅動器放在打開的機箱頂部，並且電線蜿蜒伸出，這是可以接受的；但不能接受更長的時間。）
我還假設更大的驅動器的可用性一切如常，就像我之前大約 3 年的升級一樣：1.5-3TB（2012 年）和 3-6TB（現在/不久的將來）。並且無論新的驅動器變得可用，都將足夠可靠以可用（即，突襲災難永遠不會發生）。
答案1
首先：我不會猜測未來 6-7 年的發展。這是關於今天，也是最近的未來。為了長話短說，請參閱此答案的底部。
目前，ZFS 不允許您從池中刪除 vdev。它也沒有任何本機“重新平衡”功能（搜索塊指針重寫,BP重寫或者業務流程外包重寫了解更多相關資訊）。 ZFS做允許您減少鏡像的冗餘級別，但不能減少 raidzN、vdev，但這不是您想要的。 （在 ZFS 中，條帶化是當您什麼都不說時得到的。）
基本上，池可以被認為是由一個或多個儲存裝置組成的條帶集，只有後者（vdev）可以以冗餘配置進行排列。您可以將每個 vdev 配置為任意高階的冗餘，但是每一個池中的 vdev 必須保持在其冗餘閾值以上才能使池充分發揮作用。如果 vdev 失敗，最好您只會丟失儲存在該 vdev 上的數據，並且無法主動控制哪些資料儲存在哪些 vdev 上（除了將它們放在單獨的池中，這還有其他缺點）。
當您有一個「鏡像」池（例如您在第一次擴展後描述的池）時，您真正擁有的是兩個vdev，每個vdev 由一對鏡像實體儲存裝置組成，其中這兩個vdev 被條帶化以形成池。兩個 vdev、每個鏡像兩個驅動器池可能會被一個故障驅動器關閉，並且一即使另一個鏡像群組運作正常，該鏡像群組中的另一個磁碟機上也會發生不幸的錯誤。在發生此類故障的情況下，無論發生什麼情況，您都會遺失一些資料。
提高 ZFS 池容量的正常方法是就地更換驅動器對於較大的驅動器，允許池重新同步到新驅動器上，然後物理刪除不再使用的舊驅動器。通常，人們希望zpool replace在連接舊驅動器和新驅動器的情況下使用此功能，以在整個過程中保持所需的冗餘等級。通常的替代方法是新增與池中現有 vdev 具有相同冗餘等級的 vdev。再次請注意，由於 ZFS 不支援刪除條帶集的一部分，且池嚴格由條帶 vdev 組成，因此在新增 vdev 後就無法刪除它。許多 ZFS 新手都會陷入這個陷阱，如果您不注意所使用的特定命令，很容易陷入困境。
由於 ZFS 重新同步器的工作原理，重新同步對於所涉及的驅動器來說是極其痛苦的。傳統的RAID 重新同步器通常大多是順序的，其中散佈著來自用戶活動的少量隨機I/O，而ZFS 重新同步器幾乎是完全隨機的I/O，其中散佈著來自用戶活動的隨機I/O 。一套鏡子在其整個生命週期中經歷了大致相同的活動；如果一個驅動器處於邊緣狀態，甚至已經死亡，那麼另一個驅動器很可能充其量也處於邊緣狀態。讓它連續幾天經歷重新鍍銀的考驗可能很容易將其推向崩潰的邊緣。 （根據個人經驗，我猜測，要重新同步 6 TB 數據，您將需要大約一周的重新同步過程。即使您轉動所有旋鈕最多 11 個，基於純粹的順序吞吐量——考慮到 ZFS 的磁碟格式和重新同步策略，這是完全不切實際的——您正在查看至少大約 17 個小時的車程充滿了恐懼。我最好的猜測是，沒有辦法將 6 TB 的重新同步容量降低到不到兩倍，或者一天半，徹底的驅動器濫用。
假設這類硬碟成為現實，我也會對 2x24TB 甚至 2x12TB 鏡像配置產生非常嚴重的懷疑；我們已經用目前的驅動器尺寸稍微突破了物理的界限（沒有雙關語）。假設驅動器可靠性，就尿素，仍然與今天類似（每比特讀取 10^-14 到 10^-15 扇區錯誤，這是它在製造商數據表中永遠徘徊的位置），統計上你將無法完整讀取你的數據。 12TB 驅動器沒有遇到至少一個錯誤（12TB 大約為9×10^13 位，可以很好地舍入為10^14）。當您將其推送到 24 TB 硬碟時，統計資料顯示您將達到至少一次完整讀取過程中出現一兩個全扇區錯誤（因為您正在讀取大約 2*10^14 位元）。即使您使用 10^-15 URE 驅動器，這也不會為您帶來太多好處（然後您將看到五個讀取通道，而不是一半讀取通道）。當然，這是統計數據和規格；在實踐中，讀取錯誤傾向於聚集在一起，並且驅動器可以為許多許多完整讀取提供無故障服務，然後在某個時刻開始拋出左右和中心錯誤。
鑑於大多數非伺服器旋轉器的保固期僅為 1-3 年，我不會指望任何套件能夠繼續工作比這更長的時間，而您的計劃要求它們在被取代之前至少保持功能六年。即使是伺服器旋轉器通常也只能保固五年，儘管通常是五年 24x7 運行。我個人的經驗是，高階消費性硬碟，例如希捷的 Constellation ES 系列，在放棄幽靈並進入資料天堂之前可以提供幾乎這種等級的任務。 （個人軼事：當我使用 1 TB Constellation ES.2 大約 4 年 9 至 10 個月時，它開始變得滑稽，儘管我從未讓它失敗過。）
一般來說，一旦旋轉器大小達到 3-4 TB 標記，或者對於更重要的資料而言更小，許多運行 ZFS 的人就會採用雙冗餘。這是有充分理由的：儲存設備發生故障和它發生頻率驚人。就 ZFS 而言，如果您想要的不僅僅是返回仍然可以從盤片上讀取的原始位，那麼您還會考慮更昂貴的數據恢復服務，而且我不知道有任何數據恢復軟體甚至可以遠程處理ZFS 池。如果 ZFS 無法匯入您的池，最實際的答案通常是認為丟失了您未備份的任何數據別處。
回答標題問題，TL;DR
FreeNAS/ZFS 可以讓我以這種方式管理我的儲存空間嗎
從嚴格的技術意義上來說，是的，應該是如此。但是，我真的根本不會推薦它。您將硬體的操作範圍推得太遠了讓我感到舒服，更不用說認可它了。 （請注意，無論您詢問的檔案系統如何，這個答案幾乎都是完全相同的。）