Use SSD as write cache for HDD on Windows Server 2008 R2

[JJ Johnson]

Is there a free or commercial product on the market that will let you use SSD as a write cache for hard drive storage on Windows Server 2008 R2?

 

[staticlag]

I would spend that money on maxing out the machine's RAM.

system ram is the default cache.

 

[JJ Johnson]

I commonly move tens of gigabytes in large media files across my network to hard drives on my file server. The files written are far too large for system RAM to do much good. I'd dedicate (if it must be dedicated) as much 100 GB of the SSD to this task. In testing, I can see that moving files to the server's system SSD is at least 50% faster than writing to HDD.

 

[staticlag]

You would be surprised at the effect of more RAM. How much RAM do you have currently?

Anyways for the situation you describe a SSD is utterly pointless.

Because the files ultimately have to be written to the hard drives.

Now it is:

[network file] -> (system RAM) -> hard drive

What you are wanting to do is:

[network file] -> (system RAM) -> SSD -> (system RAM) -> hard drive

ultimately you are adding unnecessary steps that will take longer.

 

[staticlag]

Or you would be better spent creating a RAID array with your drives. which would be improving the speed and reliability of the hard drives themselves.

My network:

 

[JJ Johnson]

My thinking is that if the cache is large enough, then all data can be written into SSD cache first, before being written to HDD and the HDD bottleneck removed entirely. It should be equivalent to writing directly to the SSD. (In actual use, I expect that a significant portion of the transfer should be written to disk by the time the whole transfer completes.) How long the overall process takes to complete server-side is unimportant to me. What's important is that the transfer speed as seen by the network client is faster, so the transfer takes less time.

 

[omniscence]

Intel SRT in maximum mode will use the SSD as write cache. But it is limited to 64 GB.

 

[_Gea]

It is hard to imagine when a SSD write cache can make sense.

On sequential writes disks are as fast as SSDs. A SSD cache lowers then write performance as any write must be done twice on similar fast devices (Client -> Cache -> Disk).
If you use a RAID, sequential performance of the Raid is much better than a single SSD.

This is different with small random writes where latency or iops are relevant.
In such a case a SSD can help. If you look at ZFS such a write caching is done by default to collect small random writes and write it after a few seconds as one large fast sequential write.

But for such a caching, SSDs are not helpful as this can be done in RAM much faster as the needed storage is quite low. If you want to collect 5s of random writes even on a 10 Gb network, your cache needs to be about (10 Gb=about 1 GB): 5s x 1GB = 5 GB, on a 1 Gb network only 500 MB.

The resulting problem of such a write caching is a possible dataloss in case of a power failure with RAM caching but also with SSD caching on non-Enterprise SSDs when secure sync writes are demanded by your applications. In case of ZFS this risc can be avoided with a small enterprise ZIL log device (Enterprise SSD like a Intel 3700 or DRAM based like a ZEUSRAM).

 

[-Dragon-]

"Consolidating writes" doesn't matter much on HDDs when the resulting consolidation is still spread all over the disk such as when you're using that array as storage for say a VM host and you're getting frequent writes that go into multiple virtual HD storage containers, the consolidation of the writes will still be dozens of random, likely 4k writes to multiple locations across the whole disk, and you're still likely to get yourself quickly into a situation where the IOPS coming from your VM host or cluster exceed the IOPS of the HDD only, fill up your RAM write cache, and then performance drops to the speed random IO speed of the underlying array. Stick a SSD cache in there as an intermediary, say one using those fancy enterprise SSDs in a redundant array, and now you can have as much high IOPS as you need to give time for the array to absorb those writes without also negatively affecting the read performance off the array.