Data corruption on rebooting starwind on diskbridge LUN

sunyucong · Mon Jan 06, 2014 3:12 am

Hi,

have anyone seen this before? I've been bite recently that rebooted starwind several times due to unforseeable problem, and my diskbridge based LUN is now corrput!!!! vmfs would show some directory no longer can be accessed. while another file based LUN is fine.

Have anyone seen this before? Is this a know issue? I'm very sad

Mon Jan 06, 2014 3:55 pm

Hi Sunycong,
There can be multiple reasons for this to happen.
Let's start with a little more information on your systems:
StarWind version, vSphere version, network connection details (teaming, if any).
Also, I'd like to know the cache type and size you've chosen when creating both file based device and diskbridge.
Look forward to hearing from you.

Mon Jan 06, 2014 8:38 pm

1) If you'd be running fault-tolerant StarWind config (2 nodes and up) you'd never have anything like this. Simply synchronizing to the alive node(s) would fix everything transparently to hypervisor. No file system damage, no data loss with virtually any cases.

2) If you run a single-node (which is not considered to be a production scenario) make sure you DO NOT assign write-back cache to it as huge amount of writes would be discarded with storage node rebooted. OK, we'll throw a warning message in V8 or maybe disable single node write-back cache usage.

3) Generally speaking it's a bad idea to map storage AS IS (disk bridge) as it makes recovery process complicated. We've tried many times to actually remove this mode from StarWind @ all but customers keep asking for one to be present. So probably we'll make trickier to enable one in upcoming V8.

fbifido · Tue Jan 07, 2014 6:05 am

2) If you run a single-node (which is not considered to be a production scenario) make sure you DO NOT assign write-back cache to it as huge amount of writes would be discarded with storage node rebooted. OK, we'll throw a warning message in V8 or maybe disable single node write-back cache usage.

Q1) Would not this degrade the performance of his iSCSI & dedup ?

Tue Jan 07, 2014 3:38 pm

Single node setup is not considered to be a production scenario.

fbifido wrote:
2) If you run a single-node (which is not considered to be a production scenario) make sure you DO NOT assign write-back cache to it as huge amount of writes would be discarded with storage node rebooted. OK, we'll throw a warning message in V8 or maybe disable single node write-back cache usage.
Q1) Would not this degrade the performance of his iSCSI & dedup ?