Relative Performance of Parity .vs. Mirror in Storage Spaces

I wanted to understand the performance overhead of parity .vs. 2-way mirror configuration of drives in Windows Server 2012 Storage Spaces and took notes while doing some tests.

I have constructed a disk configuration of any disk I can get hold of; from 5400RPM 2TB SATA to even a lowly laptop drive, all bundled in a single pool. From this pool I carved out two thin provisioned volumes, one two-way mirrored, one parity. It looks like this:

For those who want to know, here’s the specifics of each disk. Go look-up on the net for the model numbers for details on each disk if you like.

I then created one ReFS volume within each. Note that I have disabled the FileIntegrity feature of ReFS using the following command. I did this for both volumes I created. When you disable it at the root, all underlying files/folders created after this setting will have the FileIntegrity bit disabled. This can be enabled/disabled at the file level at any time.

• “set-FileIntegrity -Filename D:\ -enable $false”
• “set-FileIntegrity -Filename E:\ -enable $false”

Note that I will enable this later and see what kind of impact it will have on the system. For now, volumes are looking like this:

I then fired up PassMark v8 and custom-configured the disk test profile. I configured two threads going simultaneously for D and E drives at the same time for 120 seconds. I used PassMark’s standard File Server profile, which calls for a 500MB test file.

Before you ask, thin provisioned system and a test like this has some quirks to handle. First time you run this test, allocation of thinly provisioned volume will have to be built from scratch, so it’s not fair to the test scenario to absorb that sort of overhead. For that reason I ran it once completely, then ran for the second and even third time. I verified that allocation size of the virtual disks are no longer growing as I run the tests, meaning, we’re operating on the white space of the thinly provisioned volumes. This is more typical of a performance we’d get from a file server.

So here’s the initial output that I’ll share with you. As you might notice, D: drive is the turtle and E: drive is the rabbit. Pay attention to the lower “Status” section and MB/Sec column. See how low the parity protected disk is in comparison?

(Keep reading after the image)

You should NOT draw conclusions about absolute performance numbers out of my tests. My disks and the system are very old; however, in relative comparison of mirror and parity, this test should be valid.

I will now repeat the same thing with one disk at a time. After all, these disks are hosted on a single Storage Pool, meaning they are competing for resources when they are active simultaneously.

Now the question is, will they deliver similar MB/Sec figures when the test is run one-at-a-time. Here’s the test against D: drive (Parity)

Before you draw any conclusions, let’s check how E: drive (mirror) will perform:

As you can see, difference is not as drastic compared to the test pass where both drives were hit simultaneously. Perhaps this tells us that performance of a parity protected disk degrades much quickly if there are competing IO requests against the system, and less so with mirror protected disks.

Even in a best case comparison scenario, mirrored disks appear to be about 70% faster than parity disks under PassMark’s file server benchmark profile.

All of the above is caching=OFF and this is the default configuration of the standard File Server benchmark profile. Just to see what happens, I turned caching on. Here’s what E: drive could do. Keep in mind, the server has 8GB of available memory. So 500MB file is coming directly from memory.

As promised, I’ll enable now FileIntegrity in ReFS (which is default behavior) and see the impact it will have on the tests. It is enabled like this:

• “set-FileIntegrity -Filename D:\ -enable $true”
• “set-FileIntegrity -Filename E:\ -enable $true”

Here’s the uncached run (same as I had done earlier for E: drive – mirrored one). 16MB/sec value dropped to 1.3MB/sec. This is quite bad.

Let’s see how D: drive will perform. Remember, D is the one with parity protection.

FileIntegrity bit has quite an impact on random IO workloads. Let’s check how things go when both volumes are hit at the same time:

Next, let’s test how NTFS will behave. Same tests, this time disks are formatted with NTFS.

Simultaneous run:

Parity drive alone:

Mirror drive alone:

In conclusion, here are the comparison chart. Do NOT look at absolute numbers. Look at relative changes in varying settings. Values are in MB/Sec.

Given the general purpose nature of my workloads, I’ll be using NTFS.