Storage Innovations in Windows Server 2022

[AndrewHansen]

We are excited to release new features in Storage for Windows Server 2022. Our focus is to provide customers with greater resiliency, performance, and flexibility. While some of these topics have been covered elsewhere, we wanted to provide a single place where our Server 2022 customers can read about these innovations and features.

Advanced Caching in Storage Spaces

 

During Windows Server 2019, we realized that many deployments are on single, standalone server platforms (i.e., non-clustered). We wanted to deliver innovations that specifically target this popular segment of our customer base.

We developed a new storage cache for standalone servers that can significantly improve overall system performance, while maintaining storage efficiency and keeping the operational costs low. Similar to caching in Storage Spaces Direct, this feature binds together faster media (for example, SSD) with slower media (for example, high-capacity HDD) to create tiers.

Windows Server 2022 contains new, advanced caching logic that can automatically place critical data on the fastest storage volumes, while placing less-critical data on the slower, high-capacity storage devices. While highly-configurable, Windows offers a highly optimized set of defaults that allow an IT admin to “set and forget” while still achieving significant performance gains.

Learn more: Storage bus cache on Storage Spaces

 

Faster Repair/Resync

We heard your feedback. Storage resync and rebuilds after events like node reboots and disk failures are now TWICE as fast. Also, repairs have less variance in time taken so you can be more sure of how long the repairs will take. No longer will you get those long hanging repair jobs. We've done this through adding more granularity to our data tracking. This allows use to move only the data that needs to be moved. Less moved data, means less work, less system resources used, and less time taken - also less stress for you!

Adjustable Storage Repair/Resync Speed

We know that resiliency and availability are incredibly important for our users. Waiting for storage to resync after a node reboot or a replaced disk shouldn't be a nail-biting experience. We also know that storage rebuilds can consume system resources that users would rather keep reserved for business applications. For these reasons we have focused on improving storage resync and rebuilds.

In Windows Server 2022 we cut repair speeds in half! And you can go even faster with adjustable storage repair speeds.

This means you have more control over the data resync process by allocating resources to either repair data copies (resiliency) or run active workloads (performance). Now you can prioritize rebuilds during servicing hours or run the resync in the background to keep your business apps in priority. Faster repairs means increasing the availability of your cluster nodes and allows you to service clusters more flexibly and efficiently.

Learn more: Adjustable storage repair speed in Azure Stack HCI and Windows Server clusters

 

ReFS File Snapshots

Microsoft’s resilient file system (ReFS) now includes the ability to snapshot files using a quick metadata operation. Snapshots are different than ReFS block cloning in that clones are writable, snapshots are read-only. This functionality is especially handy in virtual machine backup scenarios with VHD files. ReFS snapshots are unique in that they take a constant time irrespective of file size.

Functionality for snapshots is currently built into ReFSutil or available as an API.

 

Other improvements:

• ReFS Block Cloning performance improvements.
• ReFS improvements to storage mapping in the background mapping to reduce latency.
• Various other perf and scale improvements.

[Karl_Wester-Ebbinghaus]

Hi @AndrewHansen thank you for this great article and details.
I have noticed something new in Windows 11 Enterprise you can choose smaller allocation sizes on ReFS. Has this something to do with the improved block cloning / repair?

Also I would like to have an official docs on ReFS that would use this as source Windows ReFS versions · GitHub
Another wish would be a docs about Storage Spaces Pool versions. There have been many upgrades, Win 11 brings a next one but there is no documentation I know of to list a version table of Storage Spaces and their improvements per version.
I would be glad to help working on these docs.

[Joachim_Otahal]

StorageBusCache suffers the same stupid design limitation as S2D: The drives must be connected directly. If the underlying storage layer does not expose the disktype or allows to set the disktype, for example when you try it with .VHDX, or with most RAID controllers etc, it won't work.

It checks the disk type directly when going through the steps to create and S2D/StorageBusCache setup, and clears the "SSD" flag you may have just set with set-physicaldisk.

In result: It has the same "way too narrow and specific" constellation requirements as S2D with tiering due to bad design decisions during implementation, therefore limiting broad usage.

See my whining here in extreme detail: https://github.com/MicrosoftDocs/windowsserverdocs/issues/5769

[ShanePearlman]

Thanks @AndrewHansen,

With atomic snapshots, ReFS is finally a contender in the COW filesystem lineup.  I would love to see some benchmarks comparing ReFS (w/ Storage Spaces) to ZFS and even a deep design/architectural comparison of the two.  For instance, there is a belief among ZFS proponents that Storage Spaces is not viable in a parity configuration due to poor performance.

ZFS requires a lot of tuning to recover similar performance to non-COW systems in pathological use cases, particularly as backing storage for VMs and databases.  ZFS uses a lot of RAM for read-caching, and can be configured to use dedicated, high-performance disks for that purpose.  Instead of write-caching, ZFS uses a transaction log (ZIL), which also can be configured to use dedicated, low-latency disks.  Once you're done with my other requests ;-), how about a guide to performance tuning ReFS without losing consistency or durability?

Finally, an honest comparison between these filesystems might not give a marketing-approved level of flattery to ReFS, youthful as it is, but you have ample opportunity to upstage ZFS deduplication, given that ZFS dedup design is not great.  Online (sync at write) dedup is too expensive to justify, when there is so much to gain from integrated offline (async, lazy, background, scheduled, etc) dedup.

[Karl_Wester-Ebbinghaus_business]

@AndrewHansen someone found traces of a new feature in ReFS pointing to something like block based compression (in Windows Server vNext). Are you allowed to explain a bit about it?