Introduction
This blog post is a teaser where we show you some of the results we have seen with ReFS v2 in Windows 2016 (TPv4). In a previous blog post (Lightning Fast Fixed VHDX File Creation Speed With ReFS on Windows Server 2016) we have demonstrated the very fast VHDX file creation capabilities we got with ReFS v2. Now we look at another benefit of ReFS v2 in a Hyper-V environment, thanks to a feature or ReFS v2 called block cloning. We get accelerated checkpoint merging with ReFs v2 in Windows 2016
The Demo
For this short demo we have a virtual machine running Windows Server 2016. It resides on a CSV formatted with REFS (64K unit allocation size). Inside the virtual machine there is a second data disk. Our VM called CheckPointReFS (64K unit allocation size) has this data volume formatted with ReFS (64K unit allocation size) and it runs on the ReFS formatted CSV. The disks in this test are fixed sized VHDX files.
On the data volumes we have about 30GB worth of ISO files. We checkpoint the VMs and then create a copy of those files on the data volume.
We then delete this checkpoint.
Via the events 19070 (start of a background disk merge) and 19080 (completion of a background disk merge) in the Microsoft-Windows-Hyper-V-VMMS/Admin logs we calculate the time this took: 5 seconds.
There are moments you just have to say “WAUW”. Really this rocks and it’s amazing. So amazing I figured I made a mistake and I ran it again … 4 seconds. WOEHOE! What where the times you saw when you last deleted a large checkpoint?
I am really looking forward to do more testing with ReFS v2 capabilities with Hyper-V on Windows 2016.
Does the VHDX need to be formatted in REFS to take advantage of this do you know?
Not to my knowledge. I still have a lot of testing (Clustered, non clusterd, different File systems, unit allocation sizes etc) to do and this is still a preview edition. It does seem to take a bit longer (10 to 12 seconds) when the VHDX is formatted with NTFS during my early testing but it’s still very fast
What TYPE of checkpoint is this?
Production. Type doesn’t matter for this.
Pingback: ReFS vNext Block Cloning and ODX - Working Hard In IT
Is this specific to Hyper-V only (and not just a normal server install)?
I just installed TP4 and have ceated and reFS volume . I’ve copied in a large file and then copy/pasted into the same directory and it did a normal full paste and took several minutes.
when i did an “fsinfo refsinfo E:” it pumped out the below details (reFS3.0 ??? or maybe just because its a TP).
C:\Users\Administrator>fsutil fsinfo refsinfo E:
REFS Volume Serial Number : 0x4e7c1ea17c1e83bd
REFS Version : 3.0
Number Sectors : 0x0000000004fe0000
Total Clusters : 0x00000000009fc000
Free Clusters : 0x00000000004dc0c8
Total Reserved : 0x00000000000228d8
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Checksum Type: CHECKSUM_TYPE_NONE
The version of ReFS is at 3 since TPv4 and still is at TPv5 (https://blog.workinghardinit.work/tag/refs-versions/ ), before that it was at v2 in the W2K16 TPs.
The actions and the applications have to summprt/implement ReFS capabilities, Hyper-V is one of then for file creation, merging etc, Storage Spaces Direct, … Not all file actions with all apps will use these new capabilities form day 1 or be able to under all conditions. We’ll have to wait see hwo things evolve in the future.
ok so it sounds like you’d need an API to gain the benefits?? thanks.
If you’re an ISV and you want to leverage ReFS capabilities in Windows Server 2016 you have to levergae it yes.