Write-back chaching enabled - UPS needed?

[Mc21021974]

Hello,

I installed the iSCSI Target v5.6 on my Windows Server 2008 server (64bit). I created a Target with a Image file. I enabled Write-back chaching and I am super happy with the performance. But now I am worried about the fact that with Write-back chaching enabled I might end up with a corrupt target file after a power outtage. The setup is just for my lab but still it would be not a good situation to be in.

Should I now buy a UPS and connect the server running iSCSI target to this UPS to prevent data loss in case of a power outtage?

Thank you
Marcus

[deiruch]

Write-back caching always increases the risk of data loss. Having a UPS would certainly be a good thing.

By default the expiry period of the cache is set to 5 seconds. This means you'll lose at most 5 seconds worth of data. If this is tolerable you can live without a UPS. Please note however that the filesystem on the volume might need to be repaired. Wouldn't depend on that if you were to run a nuclear power plant...

If you need more security you have the following options:
- Use a write-through cache (slows write access)
- Use a UPS (better)
- Using a HA configuration, with at least one node having UPS backup (even better)

[anton (staff)]

Simon, absolutely brilliant! You're 200% correct here! Need to admit however SAN is at least two times cached: once on initiator and once on target. So even disabling cache on target completely still
does not make whole system completely immune. To increase data loss protection host application on initiator side should be clustered itself (for example running under multi-head hypervisor). In such
a case we do at least protect ourselves from client-side hardware issues leaving application itself as a single point of failure (don't see any way how to fix this for generic apps...).

[Mc21021974]

Simon an Anton,

Loosing 5 seconds of data is not going to be a problem at all. It is a lab environment.
But how big is the chance that I will end up with a completely corrupt image file? This image file contains all my VMs.

Thank you
Marcus

[anton (staff)]

If it's a lab only I don't understand why you need screaming performance (read: Write-Back Cache).

There's no guarantee about how bad corruption would be. 5 seconds under heavy load is 500+ MB of data.

Simon an Anton,

Loosing 5 seconds of data is not going to be a problem at all. It is a lab environment.
But how big is the chance that I will end up with a completely corrupt image file? This image file contains all my VMs.

Thank you
Marcus

[Mc21021974]

Anton,

Why would I not try to get the most speed out of my equipment? Besides that you are not answering my question which is: Can I end up with a completely corrupt image file which cannot be read and mounted by the Starwind iSCSI target software or not?

Thank you

[deiruch]

You won't end up with a a file that StarWind can't read.

Worst-case scenario is that the file system gets corrupted. Similar as if you used a local disk and just pulled the plug on the server. Chances are that some data still resided in the cache and was not yet written. You might have to run checkdisk (or use Windows 7/Server 2008, because they repair the disk in the background automatically).

In practice this would mean that you might lose a file that was created 3 seconds ago or that a file is corrupted that was used recently. But you have backups anyway, right?

[Mc21021974]

Simon,

Thanks for the detailed answer. This is the information I was looking for. And yes I have backups.

Thanks again for the info.

[anton (staff)]

It's like removing whole brake system from your race car. Yes, it would accelerate faster with 50 kg of weight stripped down. Until you'd like to corner or stop. The same with write-back cache. Whole system would work much faster and have better response. Being much less reliable.

I did answer. You just did not like it. It's (re-phrase) "nobody knows". Both VMFS and NTFS are journaling so would update metadata only after real data is written so chances to have completely corrupted volume are pretty low (I've personally never seen this ever) but there's no guarantee.

Anton,

Why would I not try to get the most speed out of my equipment? Besides that you are not answering my question which is: Can I end up with a completely corrupt image file which cannot be read and mounted by the Starwind iSCSI target software or not?

Thank you

[anton (staff)]

Pretty close... Guys who use StarWind as a Tier 2 storage for backups do use Write-Back cache enabled with single node. Just b/c they do verify content after written so if backup job fails - they can always re-schedule it later after disk check and fix complete. And using Write-Back cache shrinks whole backup window (something why StarWind with multi-GB WB cache and deduplication is really in game).

You won't end up with a a file that StarWind can't read.

Worst-case scenario is that the file system gets corrupted. Similar as if you used a local disk and just pulled the plug on the server. Chances are that some data still resided in the cache and was not yet written. You might have to run checkdisk (or use Windows 7/Server 2008, because they repair the disk in the background automatically).

In practice this would mean that you might lose a file that was created 3 seconds ago or that a file is corrupted that was used recently. But you have backups anyway, right?