The nice tandem DFS setup I blogged about the other day is driving me nuts today.
Today I had 2 employees open the same file on the network share. Both of them got a different copy, and neither one was set to read only. This was a true WTF moment in the office. Of course when they tried to replicate it for me, it didn’t work as DFS managed to catch up at that point.
This is scarry and dangerous though. I found several sharing violation conflicts in the Event viewer. This was my biggest concern with DFS – how does it handle concurrency? We just can’t have concurrent writes to same office document. The only outcome of that situation is loss of one of the write operations. And that is unacceptable.
The consultant who was setting this up was swearing up and down that this wont happen. I talked to his boss today, and he was bewildered too. He thinks our problems were related to low disk space. When DFS doesn’t have space to stage replication, it suspends the process. They thing this is what happened here.
We freed up 60G of HD space. So far replication was working. I’ll give it few days to work this thing out, but I’m not entirely convinced that HD space has anything to do with concurrency.
I would also like to mention that ntbackup is a steaming pile of monkey ass shit. I’m almost ready to shell out $600+ for a veritas upgrade and a remote agent license. Not that Veritas is all that great either but at least it worked for me semi-reliably for the last 2 years…
