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:

image

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.

image

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:

image

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)

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)

image

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

image

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.

image

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.

image

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

image

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:

image

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

Simultaneous run:

image

Parity drive alone:

image

Mirror drive alone:

image

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.

image

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

About these ads

2 thoughts on “Relative Performance of Parity .vs. Mirror in Storage Spaces

  1. I think you set yourself up for disaster with running the tests on old junk hardware. While everything should be relative, nothing ever seems to work that way in real life. For solid performance testing you should have isolated variables by using like model drives, fixed virtual disks, large sample test size (4x larger than RAM minimum), more than one test software (ReFS is new FILE SYSTEM, not all test suites will work out of the box effectively, for example try out simple file copies as well since the support is baked in), and verified the drives were working optimally after each test via the get-reliability(…) PS set to make sure he did not have a bad test run / drive. Ill-conceived data just perpetuates bad information.
    Also, you should detail what the test suite is actually doing (your custom settings and information on the “file share test”), if it is all small IO then that should be explicitly detailed. There is (natural) penalties with moving to ReFS, but the benefits to your data safety greatly outweigh minor loss in performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s