I'm currently speccing out a new backup server. It's going to be running Windows Server 2012 R2 with Direct Attached Storage, and I'm considering using Storage Spaces rather than using a RAID card. (As a ZFS fan, I can definitely see the advantages of doing away with hardware RAID if done right.)

I expect my performance-critical workloads to be mostly sequential. Since this is bulk storage of sequential data, where performance of reads (backup restores) is more critical then performance of writes (taking backups), I thought parity would be a good fit to get dense and low-cost storage of backup data.

I've seen some concerning results in blogs, when it comes to write performance of parity disks, such as in this article by Derrick Wlodarz of Beta News, as well as in this white paper from Fujutsu.

When researching this more, it seems that blog article didn't test with dedicated journal disks, which can apparently can increase write performance on a parity storage space dramatically, according to this TechNet article. Unfortunately, neither of the two benchmarks I referred to earlier tested the impact of journal disks, but Microsoft claims they've seen a performance gain of 150%, which would for my application I think would put it right where I want the performance to be.

This is all good information, but there's one piece of the puzzle I've not been able to find. The SSDs in question are only to be used for journalling in a mirror, and from what I understand, they're just there to provide short-term stable storage of writes. As such, I don't expect them to have to be very large. At least, this is the conclusion I draw from working with ZFS and ZIL disks - the size is not critical, although in that case, larger disks may last longer under an intensive write load, since writes are spread across a larger disk.

I already understand that since everything written to the array will also be written to the journal, they need to be able to be written to at the desired rate. As Microsoft puts it:

Note that the throughput of the journal disks will now be the overall throughput limit to all parity spaces created on this specific storage pool and you might trade extra capacity for performance. In other words, ensure that dedicated journal disks are very fast and scale the number of journal disks with the number of parity spaces on the pool.

What I have however not been able to find, and what I hope Server Fault might be able to help me with is: Are there any best practices specifically for choosing the appropriate size of the SSDs to be used as journal disks for a Storage Space parity array?


Mate, the answer is already in the quote. You may want to add several SSDs, not big SSDs.

You were right that the journal's simply a cache for parity. But that means it's completely useless for mirrored spaces. Even the WBC is just 1GB tops for any array by default, which you can override via PowerShell, but there's also a hard limit of 100GB.

Nowadays you can't even buy an SSD smaller than 120GB. Just get them and you'll be fine. That's what I did, too.

I can also prove this with numbers, check out my in-depth benchmarking series about this:

TL;DR parity spaces sucks even with dedicated journal, just not that much. In fact, it sucks even if it's a pure SSD array. It's a shame, really. Microsoft gives a lot of blah-blah about it, but really, if MD and ZFS can do it right, why can't they?

  • Finally, some useful information on this topic! Thank you. – Per von Zweigbergk Oct 10 '15 at 5:17
  • Glad to help. Finally I also managed to do some side-by-side comparisons between Storage Spaces and ZFS, you can check them out here: Storage Spaces vs. ZFS I also opened an idea on Uservoice about adding ZFS support: ZFS on Windows Server Anyone reading this, please cast your vote, thanks :) – bviktor Oct 27 '15 at 2:45
  • Regarding your claim that "it's completely useless for mirrored spaces." According to Microsoft, for Storage Spaces Direct, you're supposed to use them as cache in a mirrored configuration - docs.microsoft.com/en-us/windows-server/storage/storage-spaces/… – Muh Fugen Aug 11 '17 at 17:41
  • Except you dont have cache in storage spaces. Crappy naming, but Storage Spaces and Storage Spaces Direct are 2 technologies - one is local (SP), one is distributed (S2D) and only the later has caching. – TomTom Apr 3 '18 at 15:51
  • The new URL for the "Storage Spaces vs. ZFS" appears to be: Storage Spaces vs. ZFS – Klaus Hartnegg Jan 9 at 15:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.