Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

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?

share|improve this answer
Finally, some useful information on this topic! Thank you. – Per von Zweigbergk Oct 10 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 at 2:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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