Hyper-V iSCSI LUNs: modern ReFS vs NTFS?

also, should we always format with 64KB allocation unit size? (not the default 4KB)

Hi ​@nd39475_c ,

I spoke to one of my Hyper V colleagues. They recommend using NTFS for 3 tier environments and ReFS for S2D and Azure Local. 

I found an older articel in the internet that states something similar.

https://teety4.rssing.com/chan-3899442/article17888.html?nocache=0#:~:text=%22Always%20use%20NTFS%20for%20your,you'd%20like%20to%20share?

Regards

Chalid

If you are asking about running VMs on the volume then you don’t need ReFS as that is typically done for a repository drive.  The normal volume for NTFS would work but the allocation unit will need to be considered depending on disk sizes.

​@Chris.Childerhose ,for completeness: this is in regards to the format of the iSCSI shared LUN, not the VM’s disks.

​@CMF , interesting article. although 2019 was when ReFS bugs were still being ironed out i presume.

thank you both!

i have interrogated AI a bit regarding Chalid feedback -- although i know AI can hallucinate.

that said I am certainly still open for more feedback.

----
 

The short answer is: Your colleague's advice is based on historical issues that have since been resolved. For Windows Server 2025, ReFS is now fully supported and recommended for shared SAN LUNs (CSVs) in a 3-tier environment.

Deconstructing the Feedback and the Old Article

The feedback you received and the article from 2019 are both referencing the same well-known issue from the Windows Server 2016 era. At that time, the advice was absolutely correct.

• "3-Tier Environment" vs. "S2D/Azure Local":

  • A 3-Tier Environment is your exact setup: Hyper-V Servers -> Network Switch -> Central SAN Storage (Dell PowerVault). The storage is separate from the compute hosts.

  • S2D (Storage Spaces Direct) and Azure Stack HCI are Hyper-Converged Infrastructure (HCI). In this model, the storage disks are inside the Hyper-V servers themselves, and software combines them into a virtual SAN.

  • Historically, ReFS was developed and optimized primarily for HCI environments (S2D). Its performance and stability on traditional SANs were not a priority, and it showed.

• The "Serious Issues and Bugs" of the Past: The article's quote, "Always use NTFS for your CSVs (Cluster Shared Volumes). ReFS has had some serious issues..." is a perfect snapshot of the sentiment around 2017-2018. Early versions of ReFS had significant problems when used on a Cluster Shared Volume (CSV) that was backed by a SAN LUN. These issues included:

  • Poor Performance: All metadata operations for the ReFS volume had to be funneled through a single "coordinator" node in the cluster, creating a massive I/O bottleneck. This was not the case with NTFS.

  • Stability Problems: There were documented cases of volumes becoming corrupted or going offline under stress, exactly as the article mentions.

  • Lack of Support: Because of these issues, Microsoft and storage vendors often recommended NTFS as the only supported file system for SAN-backed CSVs.

Fact-Check for Windows Server 2025 and Shared LUNs

The situation has changed completely. Starting with improvements in Windows Server 2019 and maturing significantly in Server 2022 and 2025, ReFS is now a first-class citizen for all Hyper-V storage configurations.

1. Direct I/O for CSVs was Introduced: The primary performance bottleneck was fixed. ReFS on a Cluster Shared Volume can now use Direct I/O, allowing all nodes in the cluster to write directly to the SAN LUN simultaneously. This brings its performance in a 3-tier environment up to par with NTFS and allows it to scale effectively.

2. Stability and Maturity: Microsoft has invested heavily in hardening ReFS. The stability issues that plagued early versions on CSVs have been resolved through years of updates. It is now considered as stable as NTFS for this purpose.

3. Full Feature Benefit: With the performance and stability issues fixed, you can now safely take advantage of the key ReFS features on your shared PowerVault LUN:

   • Block Cloning: Dramatically accelerates operations that happen on a shared VHDX file, like checkpoint merges after a Veeam backup.

   • Resiliency: The data integrity streams and checksums in ReFS provide superior protection against data corruption on your SAN.

Conclusion for Your Environment

Your colleague's advice was based on valid, but now outdated, information. The distinction they made between 3-tier and HCI environments was the correct best practice for many years.

However, for a new build on Windows Server 2025, that distinction is no longer relevant for file system choice. The technical limitations that led to the "NTFS for SANs" rule have been engineered out of the modern operating system.

You can confidently proceed with the recommendation to use ReFS with a 64KB block size for your shared iSCSI LUNs (CSVs) on your Dell PowerVault ME5. You will gain the modern performance and data integrity benefits without the stability risks of the past.

Yes I knew which LUN you were referring to but seems you have a good answer.  Did not realize now you can use ReFS for those types of volume.  Learned something new today 😁

I was led to this forum thread by an AI, so we are now at a point where AI uses previously generated AI answers to provide citations and it looks like it was again wrong - I think I’m gonna stick to NTFS...

To delete

Hi ​@nd39475_c 

check thsi link can help.

NTFS vs ReFS for hyper-v volume hosting - Microsoft Q&A

ReFS is optimized for virtualized workloads, providing better performance, scalability, and resiliency.

Confirming `FileSystemRedirected` on all my ReFS formatted iSCSI LUN. 🙁

We do not use S2D.

Qty 37 ReFS 64kb formatted LUN
Total Provisioned Disks: 205 TB
Total Used Disks: 157 TB

I used AI and `MCP microsoft learn` to corroborate that NTFS should have been used (polar opposite to previous AI interrogation).

That said, we’ve been running 100% migrated off VMWare since April 2026 with zero disk-corruption issues.  Noticeable VM speed decreases even on VM’s that are ultra-low disk I/O -- an acceptable (required) trade-off due to unacceptable Broadcom pricing.

Thanks for the bump/update -- continuing to investigate including I/O measurement for consideration (or not) of migration to NTFS.

let us know if you resolved it and mark the answer that helped you the most, thanks