實測 ReFS 檔案層級快照，儲存效率效能雙重進化 | 網管人 235 期



網管人雜誌

本文刊載於 網管人雜誌第 235 期 - 2025 年 8 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

隨著最新 Windows Server 2025 雲端作業系統的發佈，雖然傳統的 NTFS 檔案系統，為了相容於舊版的需求而未退場並持續存在，然而新世代「彈性檔案系統」（Resilient File System，ReFS），除了不斷增強原有功能之外，也持續推出各項亮眼新功能。

最初第一代的 ReFS v1.1 版本檔案系統，隨著 Windows Server 2012 作業系統一同發佈，這時的 ReFS 檔案系統僅支援資料磁碟用途，不支援開機磁碟區的工作任務。事實上，ReFS 檔案系統設計的初衷，希望能夠改善並克服舊有 NTFS 檔案系統的各種問題，ReFS 主要設計結構採用 B+Tree 的方式，將資料可用性最大化，並支援跨各種工作負載的大型資料集，同時提供資料自動化完整性檢查、快速資料清理、支援超長路徑和檔名……等特色功能。

下列為 ReFS 檔案系統演進版本和重要功能，以及哪些作業系統版本支援哪些 ReFS 版本：
  • ReFS v1.1： 整合於正式推出的 Windows Server 2012 作業系統版本中。
  • ReFS v1.2： 整合於 Windows 8.1、Windows 10 RTM 和 v1607、Windows Server 2012 R2，以及 Windows Server 2016 版本中，在格式化磁碟區時支援採用 ReFSv1 格式。
  • ReFS v2.0： 整合於 Windows Server 2016 TP2 和 TP3 版本中，其它後續新版本無法掛載使用。
  • ReFS v2.2： 整合於 Windows 10 10049 預覽版本中，其它後續新版本無法掛載使用。
  • ReFS v3.0： 整合於 Windows Server 2016 TP4 和 TP5 版本中。
  • ReFS v3.1： 整合於 Windows Server 2016 RTM 版本中。
  • ReFS v3.2： 整合於 Windows 10 v1703 版本，以及 Windows Server Insider Preview build 16237 版本中，只有伺服器版本才支援重複資料刪除特色功能。
  • ReFS v3.3： 整合於 Windows 10 v1709 企業版和 Windows Server v1709 版本中。
  • ReFS v3.4： 整合於 Windows 10 v1803 工作站和企業版，以及 Windows Server 2019 版本中。
  • ReFS v3.5： 整合於 Windows 11 Enterprise Insider Preview 19536 版本中，新增支援「硬式連結」（Hard Links），僅適用於新格式化的磁碟區啟用此功能，無法支援將舊有磁碟區升級版本後使用。
  • ReFS v3.6： 整合於 Windows 11 Enterprise Insider Preview 21292 版本，和 Windows Server Insider Preview 20282 版本中。
  • ReFS v3.7： 最初整合於 Windows 11 Enterprise Insider Preview 21313 版本，和 Windows Server Insider Preview 20303 版本中，最後和 Windows 11 和 Windows Server 2022 版本一同提供，此版本新增支援「檔案層級快照」（File-Level Snapshot） 特色功能。
  • ReFS v3.9： 整合於 Windows 11 Enterprise Insider Preview 22598 版本，和 Windows Server Insider Preview 25099 版本中，此版本新增支援 LZ4 後續壓縮處理 ，以及 ZSTD 透明解壓縮  等特色功能。
  • ReFS v3.10： 整合於 Windows 11 Enterprise Insider Preview 25324 版本，和 Windows Server Insider Preview 25324 版本中。
  • ReFS v3.12： 整合於 Windows 11 Enterprise Insider Preview 26002 版本中。
  • ReFS v3.14： 整合於 Windows 11 26047 版本中。

新世代 ReFS 檔案系統，設計目的便是為了支援超大型資料集（數百萬 TB），並且不會對效能產生負面影響。舉例來說，在傳統 NTFS 檔案系統磁碟區和檔案大小方面，最大僅支援至「256 TB」，而新世代的 ReFS 檔案系統則提升 136.7 倍支援至「35 PB」。

此外，新世代 ReFS 檔案系統，在新式工作負載的支援度上，相較於傳統 NTFS 檔案系統也更為全面，舉例來說，在 HCI 超融合運作環境中，僅 ReFS 檔案系統支援使用鏡像加速同位元磁碟區，而傳統 NTFS 檔案系統並不支援（如圖 1 所示）。

圖 1、新世代 ReFS 相較於傳統 NTFS 檔案系統支援新式工作負載
圖片來源： Resilient File System（ReFS）overview | Microsoft Learn

值得注意的是，新世代 ReFS 檔案系統雖然支援新式工作負載，然而並未完全取代傳統 NTFS 檔案系統所有功能，舉例來說，檔案系統壓縮、檔案系統加密、磁碟配額、ODX 卸載資料傳輸……等並不支援（如圖 2 所示），所以企業或組織要以新世代 ReFS 取代傳統 NTFS 檔案系統之前，必須確認相關特色功能是否支援後，才進行檔案系統的取代任務。

圖 2、新世代 ReFS 和 NTFS 檔案系統傳統特色功能比較表
圖片來源： Resilient File System（ReFS）overview | Microsoft Learn





ReFS 檔案系統特色功能

新世代 ReFS 檔案系統，支援許多現代化工作負載，舉例來說，在 Azure Local 超融合運作環境  中，支援 ReFS 原生儲存重複資料刪除和壓縮（如圖 3 所示），可協助系統最佳化記憶體使用量並降低記憶體使用成本，同時針對活躍和效能敏感或大量讀取的工作負載，以最佳化靜態與動態工作負載儲存效率的技術，舉例來說，非常適合用於檔案伺服器和 VDI 虛擬桌面等工作負載。

圖 3、ReFS 原生儲存重複資料刪除和壓縮技術啟用示意圖
圖片來源： 在 Azure Local 環境中，使用 ReFS 重複資料刪除和壓縮功能 | Microsoft Learn



鏡像加速同位元

相信 IT 管理人員，對於 RAID 磁碟陣列概念並不陌生，然而，每種類型的磁碟陣列都有其優點和缺點，而 「鏡像加速同位元」（Mirror-Accelerated Parity） 技術，便是將「鏡像」（Mirror）和「同位元」（Parity），這兩種不同儲存空間效率和效能特性整合在一起，提供將 SSD 固態硬碟和傳統 HDD 機械式硬碟，這兩者的儲存空間進行整合的技術，達到資料讀寫效能大幅提升，同時具備大容量儲存空間的目的。

在 ReFS 檔案系統中，使用鏡像加速同位元技術時，系統會即時在鏡像與同位元之間輪替資料，透過這種機制使得新資料的寫入速度，能夠快速寫入並存放至鏡像區提升儲存效能，然後再寫入至同位元區以提升儲存效率。簡單來說，熱資料會先被快速寫入於鏡像區，而冷資料則會透過儲存於同位元區，以便更有效率的使用儲存空間，達到整體儲存資源高效能表現和低成本儲存的目的。

此外，為了進行鏡像區與同位元區之間的資料輪替，ReFS 檔案系統會先將磁碟區，以邏輯的方式劃分出多個 64 MB 資料區塊（如圖 4 所示），這些眾多的資料區塊便是資料進行輪替時的基本儲存單位。

圖 4、鏡像加速同位元技術以邏輯方式切割出 64MB 資料區塊
圖片來源： 鏡像加速同位元 | Microsoft Learn

至於鏡像加速同位元技術，是如何完成鏡像與同位元之間輪替資料動作的 ？簡單來說，當鏡像層級資料達到特定儲存空間門檻值時，ReFS 檔案系統便會開始將完整的資料區塊，從鏡像區轉換至同位元區，但實際上並不會立即執行遷移資料的動作，而是盡可能將資料保留在鏡像區當中，確保持續提供最佳儲存效能，而在資料從鏡像區遷移至同位元區的過程中，系統會先讀取資料並計算出同位元編碼後，才將處理過後的資料再寫入同位元區內（如圖 5 所示）。

圖 5、將鏡像區資料處理並轉換後寫入同位元區示意圖
圖片來源： 鏡像加速同位元 | Microsoft Learn



資料區塊複製

「資料區塊複製」（Block Cloning） 技術，讓 ReFS 檔案系統能夠代表應用程式，複製檔案中的特定範圍，目標檔案可以與來源檔案相同或相異，這對於傳統的資料複製操作來說成本太高，因為必須針對底層實體資料進行大量資料的讀寫作業後才能達成。

因此，相較之下，ReFS 檔案系統的資料區塊複製技術，透過中繼資料執行資料複製作業，而無須直接讀取或寫入資料，同時允許多個檔案共享相同的邏輯叢集，也就是儲存磁碟上的實體儲存位置，因此資料的複製動作，只需要重新對應檔案區域至另一個物理位置即可（如圖 6 所示），有效將原本操作成本高昂的物理操作，轉換為處理快速的邏輯操作，除了資料複製過程更快速完成之外，還同時降低儲存層的 I/O 效能開銷。

圖 6、資料區塊複製技術檔案重新對應區域運作示意圖
圖片來源： ReFS 上的資料區塊複製 | Microsoft Learn

此外，資料區塊複製技術同樣提升 Hyper-V 虛擬化工作負載的執行效率，特別是針對 .vhdx 虛擬磁碟執行檢查點合併動作時，相較於過往能夠更快速處理完成。同時，因為多個檔案可以共享相同的邏輯叢集，相同的資料不會被多次儲存於不同物理位置，有效提升儲存空間的使用效率。





實戰 – WS2025 ReFS 檔案層級快照技術

在實戰演練小節中，將採用最新 Windows Server 2025 雲端作業系統，內建的 ReFS 檔案系統「檔案層級快照」（File-Level Snapshots）特色功能，並且與傳統快照機制進行比較，以便管理人員能夠體驗，以「快速中繼資料操作」（Quick Metadata Operation）方式建立快照檔案，和傳統快照的差異為何。

此外，ReFS 檔案層級快照和資料區塊複製機制，在運作方式上也有很大的不同並且互補，因為ReFS 區塊複製機制資料為「可寫入」（Writable）狀態，而 ReFS 檔案快照後的資料則是「唯讀」（Read-Only）狀態，這兩種機制的特性非常適合整合於 Hyper-V 虛擬化平台中，舉例來說，針對 VHDX 虛擬磁碟檔案的備份情境特別具備優勢，因為 ReFS 檔案快照機制，無須考慮備份 VM 虛擬主機的檔案大小，而是一律採用固定的時間即可完成快照檔案的建立，能夠有效縮短 VM 虛擬主機建立快照，所需花費的時間和儲存資源。



安裝 Hyper-V 虛擬化伺服器角色

首先，為實作演練的 Windows Server 2025 主機，安裝 Hyper-V 虛擬化伺服器角色。請在開啟伺服器管理員後，依序點選「Manage > Add Roles and Reatures > Role-based or feature-based installation」，在 Server Roles 安裝伺服器角色頁面中勾選「Hyper-V」選項，系統將會同時安裝相關Hyper-V 伺服器功能，當 Hyper-V 安裝程序完成後，需要重新啟動主機才會套用生效。

值得注意的是，倘若實作主機處於 Azure 公有雲環境時，在建立 Azure VM 虛擬主機流程中，於Security type 的部份預設值為「Trusted launch virtual machines」，必須調整為「Standard」設定值（如圖 7 所示），VM 虛擬主機 Size 必須採用「D 和 E 系列」，並且作業系統必須選擇單純的「Windows Server 2025 Datacenter – x64 Gen2」版本，才能順利安裝 Hyper-V 虛擬化伺服器角色，倘若採用新式的「Azure Edition 或 Azure Edition Hotpatch」版本，將會導致 Hyper-V 虛擬化功能安裝失敗。

圖 7、Azure VM 虛擬主機 Security type 調整為 Standard 才能安裝 Hyper-V 伺服器角色



建立 ReFS 和 NTFS 磁碟區

為了便於比較傳統 NTFS 檔案系統，以及新式 ReFS 檔案系統的差異，預先在 Windows Server 2025 主機中，除了系統預設磁碟區之外，額外配置 3TB SSD 固態硬碟後，將其中 1.5TB 儲存空間格式化為 ReFS 檔案系統，並指派磁碟機代號為「R：」，剩餘 1.5TB 儲存空間則格式化為 NTFS 檔案系統，並指派磁碟機代號為「N：」（如圖 8 所示）。

圖 8、同一個 SSD 固態硬碟分別格式化 ReFS 和 NTFS 檔案系統磁碟區

在開始實作之前，為了確保後續實作順利，需要先確認實作的 ReFS 檔案系統磁碟區，至少需要為「ReFS v3.7」或後續版本，才能正確支援 ReFS 檔案層級快照機制。請開啟命令提示字元，鍵入「fsutil fsinfo refsInfo R：」指令，即可查詢 ReFS 檔案系統磁碟區資訊，本文實作環境為最新「ReFS v3.14」版本，能夠正確支援 ReFS 檔案層級快照機制（如圖 9 所示）。

圖 9、檢查 ReFS 檔案系統磁碟區資訊

當然，管理人員也可以鍵入「fsutil fsinfo volumeInfo」指令，搭配 NTFS 或 ReFS 磁碟區代號，直接查詢有關 NTFS 和 ReFS 檔案系統磁碟區功能清單。舉例來說，鍵入「fsutil fsinfo volumeInfo R：」指令，即可查看 ReFS 檔案系統磁碟區支援哪些特色功能，例如，支援 Stream Snapshots、USN Journal、Block Cloning…… 等特色功能（如圖 10 所示）。

圖 10、查詢 ReFS 檔案系統支援哪些特色功能



測試建立 VHDX 虛擬磁碟效能

事實上，在新式 ReFS 檔案系統中，Block Cloning 和 Sparse VDL 這兩項儲存特色功能，便是針對 Hyper-V 虛擬化或 Azure Local 超融合運作環境，都能夠大幅提升 VM 虛擬主機的儲存效能，進而提升整體工作負載的表現。

舉例來說，Block Cloning 技術能夠加速資料區塊的複製任務，讓 VM 虛擬主機在執行檢查點合併工作任務時，除了降低對系統工作負載的影響之外，還能大幅降低整體執行時間，而 Sparse VDL 技術則是將 ReFS 檔案系統中的檔案，於建立檔案時設定為「快速歸零檔案」（Zero Files Rapidly），有效降低建立 VM 虛擬主機時，採用「固定」（Fixed）虛擬硬碟格式時所花費的時間。

現在，於 Windows Server 2025 主機中，在同一個 3TB 儲存空間的 SSD 固態硬碟中，分別建 NTFS磁碟區（N:）和 ReFS 磁碟區（R:），然後透過 PowerShell 指令，分別在 NTFS 磁碟區和 ReFS 磁碟區中，建立固定格式且儲存空間為 1.3TB 的 VHDX 虛擬硬碟，並觀察在 NTFS 磁碟區和 ReFS 磁碟區中所需花費的時間。

請在 PowerShell 指令視窗中，鍵入「Measure-Command {New-VHD -SizeBytes 1433GB -Path N:\VM-NTFS.vhdx -Fixed}」指令，在 NTFS 磁碟區中建立 1.4TB 並採用固定格式的 VHDX 虛擬硬碟，接著鍵入「Measure-Command {New-VHD -SizeBytes 1433GB -Path R:\VM-ReFS.vhdx -Fixed}」指令，在 ReFS 磁碟區中建立 1.4TB 並採用固定格式的 VHDX 虛擬硬碟（如圖 11 所示）。

圖 11、在 NTFS 和 ReFS 磁碟區分別建立 1.4TB 固定格式 VHDX 虛擬硬碟

從指令的執行結果中可以看到，即使 VHDX 虛擬硬碟存放在同一個 SSD 固態硬碟中，但分別採用傳統 NTFS 檔案系統，和新式 ReFS 檔案系統，在建立 1.4TB 固定格式 VHDX 虛擬硬碟時，所花費的時間卻差異如此巨大，在本文實作環境中 NTFS 磁碟區花費「15,136 秒」，而 ReFS 磁碟區則僅花費「3 秒」，整體效率相差「5,045 倍」，可想而知在 VM 虛擬主機運作於新式 ReFS 檔案系統時，對於工作負載效能的提升，和傳統 NTFS 檔案系統相較之下有著非常明顯的差異。



Hyper-V 虛擬化層級快照

現在，為了實際針對 VM 虛擬主機，在 NTFS 和 ReFS 檔案系統中採用不同的快照機制進行比較，請分別在 NTFS（N:）和 ReFS 磁碟區（R:）建立 VM 虛擬主機。

在 Hyper-V 虛擬化基礎架構中，管理人員可以隨時針對運作中的 VM 虛擬主機建立「檢查點」（Checkpoint），也就是舊稱為「快照」（Snapshot）的運作機制。為 VM 虛擬主機建立檢查點的時機，通常是為了重大安全性更新或軟體及應用程式大版本更新前建立，以便更新失敗或更新後有臭蟲時，能夠快速將 VM 虛擬主機回到建立檢查點時間，倘若順利完成更新作業則執行合併檢查點的動作即可。

值得注意的是，許多管理人員在重大版本更新作業完成後，因為需要進行許多測試程序和驗證項目，而忘記必須將 VM 虛擬主機執行合併檢查點的動作。事實上，一旦 VM 虛擬主機建立檢查點之後，便會產生「.avhdx」差異檔案，以便系統記錄建立檢查點後 VM 虛擬主機所有的異動，而「差異硬碟」（Differencing vDisk）格式便是儲存效能表現最差的格式。

舉例來說，管理人員為 VM 虛擬主機建立檢查點之後，針對 VM 虛擬主機進行基本操作，例如，建立檔案和資料夾再刪除、啟動或停用系統服務……等，並且觀察 .avhdx 檔案的變化，便能發現這個差異檔案的大小，將會因為 VM 虛擬主機的各項操作而不斷增長，這就是前述差異硬碟主要記錄所有異動的原因。倘若，VM 虛擬主機再次建立新的檢查點，系統將會再產生另一個 .avhdx 差異檔案，並且記錄所有和第一個差異硬碟的差異，然後隨著資料變動儲存空間不斷增長（如圖 12 所示）。

圖 12、VM 虛擬主機建立檢查點產生差異硬碟記錄所有變更



ReFS 檔案系統層級快照

ReFS 檔案系統層級快照，採用快速中繼資料操作的方式建立快照檔案，除了有效縮短 VM 虛擬主機建立快照所花費的時間成本之外，也不像 Hyper-V 虛擬化層級般，因為記錄所有變更而產生差異硬碟。在本文實作環境中，將使用 ReFSUtil 指令工具，建立和管理 ReFS 檔案層級快照，值得一提的是，ReFS 檔案系統層級快照機制，也支援採用 API 進行建立和管理。

建立 ReFS 檔案系統層級快照的方式很簡單，請切換至存放於 ReFS 檔案系統的 VM 虛擬主機磁碟區，執行「refsutil streamsnapshot /c "ReFS_snapshot_01" VM-on-ReFS.vhdx」指令後，即可看到系統回應執行成功的訊息，和剛才 Hyper-V 虛擬化層級快照機制相較之下，ReFS 檔案系統層級快照的建立幾乎是瞬間完成。

當管理人員需要查詢，剛才建立的 ReFS 檔案快照資訊時，只要將剛才建立時的參數由「/c」更改為「/l」即可，請執行「refsutil streamsnapshot /l "ReFS_snapshot_01" VM-ReFS.vhdx」指令，即可查詢剛才為 VM 虛擬主機建立的 ReFS 快照資訊，從指令執行結果中可以看到，建立的 ReFS 快照檔案才佔用「11.6 GB」儲存空間（如圖 13 所示），與剛才 Hyper-V 虛擬化層級快照後，初始產生的差異檔案儲存空間佔用相差極大。

圖 13、為 VM 虛擬主機建立 ReFS 快照並查詢快照資訊

成功建立 ReFS 快照後，請和先前建立 Hyper-V 虛擬化層級快照一樣的測試方式，針對 VM 虛擬主機進行相關基本操作後，再次建立另一個 ReFS 快照，當 VM 虛擬主機具備多份 ReFS 快照時，管理人員可以善用「萬用字元」（wildcards）參數，同時查詢和顯示多筆 ReFS 快照資訊。

請鍵入「refsutil streamsnapshot /c "ReFS_snapshot_02" VM-ReFS.vhdx」指令，針對 VM 虛擬主機再次建立 ReFS 快照，鍵入「refsutil streamsnapshot /l "ReFS_snapshot_*" VM-ReFS.vhdx」指令，同時查詢多筆 ReFS 快照資訊，從結果中可以看到，針對 VM 虛擬主機同樣的基本操作下，在 Hyper-V 虛擬化層級快照中，產生的差異檔案儲存空間佔用較大，並且隨著各項操作越多時檔案空間會不斷增長，而 ReFS 快照則是固定大小且佔用的儲存空間不會再變動（如圖 14 所示）。

圖 14、一次查詢多個 ReFS 快照資訊

管理人員可以隨時查詢和管理 ReFS 快照，舉例來說，查詢單筆 ReFS 快照內容，或是第一份與第二份 ReFS 快照之間有哪些變動，只要在 VHDX 虛擬硬碟結尾加上「：快照名稱」即可。舉例來說，請執行「refsutil streamsnapshot /q "ReFS_snapshot_01" VM-ReFS.vhdx:ReFS_snapshot_02」指令，即可查看第一份和第二份 ReFS 快照之間有哪些異動，可惜的是目前系統的顯示方式，並非人類容易閱讀的資訊，相信後續的版本將會持續改進。

當管理人員需要刪除 ReFS 快照檔案時，只需要將剛才的「/q」參數改為「/d」即可，舉例來說，執行「refsutil streamsnapshot /d "ReFS_snapshot_03" VM-ReFS.vhdx」，即可刪除第三筆 ReFS 快照檔案。





結語

透過本文的深入剖析和實戰演練後，相信管理人員對於新世代 ReFS 檔案系統有更深層的認識之外，透過實戰演練並比較傳統 NTFS 和 ReFS 檔案系統快照功能，雖然展現出 ReFS 檔案系統的強大，但美中不足的是尚未完備所有功能，例如，查詢多份 ReFS 快照有哪些異動時，顯示的資訊是目前人類無法輕易判讀的資訊，然而隨著 ReFS 檔案系統版本不斷增強，相信後續 ReFS 各項特色功能將更容易使用於企業和組織的各項營運服務。
於