In my attempt to deploy ReFS into a Production environment, I did some testing to see what sort of performance hit I should expect. As it turns out, it doesn't look bad, especially considering the benefits I'm after (protection against bit rot). Be aware that what I was most concerned about was the differences between the 3 configurations I looked at.
I used 6 physical drives; all 10k HDDs in the same DAS enclosure. 2 were in a hardware RAID-1 array at the DAS level. The next 2 were also in a hardware RAID-1 array at the DAS level. The last 2 were setup as JBOD (Dell's app makes me set them up as a single-disk RAID-0). So Windows sees a total of 4 drives.
One of the RAID-1 drives was formatted as NTFS ("raid1, ntfs"). The other RAID-1 drive was formatted as ReFS ("raid1, refs"). The last 2 were added to a "manual" Storage Spaces Pool, then I explicitly created a Storage Spaces mirror from those 2 drives and formatted the resulting volume as ReFS ("ss-m, refs"). Yes, I had to find an extra drive to add to the pool because of a dumb Microsoft limitation.
Since my environment was a Windows 2012 r2 Cluster that's hosting some Hyper-V VMs, I then made those 3 volumes into CSVs so I could use them in the cluster as expected. I then created a new 200GB dynamic VHDX and attached it to a running, clustered VM. I created it on the NTFS volume, then SLM'd (Storage Live Migration) the VHDX between the volumes as needed.
From within the VM, I ran CrystalDiskMark. Yes, that means that "on top" of the listed volume types, there's always "CSVFS", then a VHDX file, and NTFS within that, which is where the test runs.
Each test-set was set to 5 runs at 4GB each. Since I created a dynamic VHDX, I ran the test-set once to ensure disk expansion wasn't an issue. Then I ran the test-set a second time. (Since SLM'ing results in the VHDX getting compacted/optimized (like what you do with the Optimize-VHD PowerShell cmdlet), I made sure I ran the test-sets at least twice for each volume.) It turns out that it didn't matter. CrystalDiskMark creates a 4GB file during the "Preparing..." stage, so disk-expansion never impacts the tests themselves.
After I was done, I took an average of all my test-sets and created some graphs in Excel. Each volume was tested twice, except for "ss-m, refs", which was done 3 times. For the most part, I feel there wasn't significant variability between test-sets for a given volume, so I'm confident in a simple average.
Enjoy!
I used 6 physical drives; all 10k HDDs in the same DAS enclosure. 2 were in a hardware RAID-1 array at the DAS level. The next 2 were also in a hardware RAID-1 array at the DAS level. The last 2 were setup as JBOD (Dell's app makes me set them up as a single-disk RAID-0). So Windows sees a total of 4 drives.
One of the RAID-1 drives was formatted as NTFS ("raid1, ntfs"). The other RAID-1 drive was formatted as ReFS ("raid1, refs"). The last 2 were added to a "manual" Storage Spaces Pool, then I explicitly created a Storage Spaces mirror from those 2 drives and formatted the resulting volume as ReFS ("ss-m, refs"). Yes, I had to find an extra drive to add to the pool because of a dumb Microsoft limitation.
Since my environment was a Windows 2012 r2 Cluster that's hosting some Hyper-V VMs, I then made those 3 volumes into CSVs so I could use them in the cluster as expected. I then created a new 200GB dynamic VHDX and attached it to a running, clustered VM. I created it on the NTFS volume, then SLM'd (Storage Live Migration) the VHDX between the volumes as needed.
From within the VM, I ran CrystalDiskMark. Yes, that means that "on top" of the listed volume types, there's always "CSVFS", then a VHDX file, and NTFS within that, which is where the test runs.
Each test-set was set to 5 runs at 4GB each. Since I created a dynamic VHDX, I ran the test-set once to ensure disk expansion wasn't an issue. Then I ran the test-set a second time. (Since SLM'ing results in the VHDX getting compacted/optimized (like what you do with the Optimize-VHD PowerShell cmdlet), I made sure I ran the test-sets at least twice for each volume.) It turns out that it didn't matter. CrystalDiskMark creates a 4GB file during the "Preparing..." stage, so disk-expansion never impacts the tests themselves.
After I was done, I took an average of all my test-sets and created some graphs in Excel. Each volume was tested twice, except for "ss-m, refs", which was done 3 times. For the most part, I feel there wasn't significant variability between test-sets for a given volume, so I'm confident in a simple average.
Enjoy!
Comments