On 2005-03-19T12:43:41, "Peter T. Breuer" <ptb@xxxxxxxxxxxxxx> wrote: > Well, there is the "right data" from our point of view, and it is what > should by on (one/both?) device by now. One doesn't get to recover that > "right data" by copying one disk over another, however efficiently one > does it. It's about conflict resolution and recovery after a split-brain and concurrent service activation has occured. Read up on that here: http://www.linux-mag.com/2003-11/availability_01.html (see the blob about split-brain with drbd). It all depends on the kind of guarantees you need. > But neither mirror is necessarily right. We are already in a bad > situation. There is no good way out. You can merely choose which of > the two data possibilities you want for each block. They're not > necesarily either of them "right", but one of them may be, but which one > we don't know. It's quite clear that you won't get a consistent state of the system by mixing blocks from either side; you need to declare one the 'winner', throwing out the modifications on the other side (probably after having them saved manually, and then re-entering them later). For some scenarios, this is acceptable. > Why should one think that copying all of one disk to the other (morally) > gets one data that is more right than copying some of it? Nothing one > can do at this point will help. It's not a moral problem. It is about regaining consistency. Which one of the datasets you choose you could either arbitate via some automatic mechanisms (drbd-0.8 has a couple) or let a human decide. The default with drbd-0.7 is that they will detect this situation has occured and refuse to start replication unless the admin intervenes and decides which side wins. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
