StarWind Software

Hi,
If a Starwind server suffers a blue-screen, hard shutdown, or any other event that prevents a graceful shutdown, will using a Write-back cache potentially cause problems with data corruption since it's conceivable that there are writes in the cache that haven't been written to disk yet?

Thanks,
Elvis

StarWind is clustered solution and is assumed to be run with dual or triple "controller" (or gateway) nodes. If one node will go down you'll have at least one (or better two) nodes having the same data written to medium.
So it's 99.99% - 99.9999% (dual vs. triple) safe to have write back cache of any size. This is VERY different from ordinary "generic" single controller solutions.

epalombizio wrote:Hi,
If a Starwind server suffers a blue-screen, hard shutdown, or any other event that prevents a graceful shutdown, will using a Write-back cache potentially cause problems with data corruption since it's conceivable that there are writes in the cache that haven't been written to disk yet?

Thanks,
Elvis

Thanks,
If I'm using an HA cluster as specified and a write is cached to the WB cache and a write acknowledgement is sent back to the client and the server fails, I'm not sure how HA would help me since the ISCSI client thinks the write was successful, even though it never made it to disk.

I assume that if I'm NOT running an HA target, the write-back cache does bring about more risk than using write-through?

Thanks,
Elvis

If it's not written to disk because of a failure node will be marked as "failed" and will stop accepting I/Os. Up to the time it would be synchronized with healthy nodes within the cluster (who have the same data processed correctly).

Absolutely. With a single node it's safer to use write-thru. Write-back could be used if you have a good backup to recover from.

epalombizio wrote:Thanks,
If I'm using an HA cluster as specified and a write is cached to the WB cache and a write acknowledgement is sent back to the client and the server fails, I'm not sure how HA would help me since the ISCSI client thinks the write was successful, even though it never made it to disk.

I assume that if I'm NOT running an HA target, the write-back cache does bring about more risk than using write-through?

Thanks,
Elvis

Ok, if data is written to the Write-Back cache, but not yet replicated to the HA partner, the ISCSI client wouldn't see a ACK for the data write since it needs to be written to both partners? So the synchronous writes must happen before the write to cache, and then the write from cache to disk?

So the synchronous writes must happen before the write to cache, and then the write from cache to disk?

Would you please clarify that?

I'm just trying to think if there is any possible situation where a WB cache could hurt in an HA configuration.

I was thinking that if a write is made to Server1's WB Cache, an ACK is sent back to the iscsi client. If Server1 suffers a failure before the write is made to Server2, then there could be an instance where the client thinks data was written when in fact it isn't written on Server2.

If the Starwind algorithm dictates that writes need to be written to both HA partners (WB cache or not), then there would be no risk.. Is this how it works?

Thanks

It does not work this way. ACK is sent back to caller only on caches being coherent. No issue.

epalombizio wrote:I'm just trying to think if there is any possible situation where a WB cache could hurt in an HA configuration.

I was thinking that if a write is made to Server1's WB Cache, an ACK is sent back to the iscsi client. If Server1 suffers a failure before the write is made to Server2, then there could be an instance where the client thinks data was written when in fact it isn't written on Server2.

If the Starwind algorithm dictates that writes need to be written to both HA partners (WB cache or not), then there would be no risk.. Is this how it works?

Thanks