Jonathan Brassow [jbrassow@xxxxxxxxxx] wrote: > > Let's say that the primary copy of the log dies or goes offline. You > continue on because the log device is still "good". If your machine > crashes and the primary log device is "rediscovered" on bootup, what > happens? The contents of the stale side will be copied - resulting > in your log not properly reflecting the state of your mirror device > and maybe even leaving inconsistencies. How does this work today with a normal mirror (does the disk log keep enough info who should be the master on reboot?)? > Ultimately, I think that in order to have a fast solution that allows > you to do the above (as well as a whole host of other advanced > features, like real-time mirroring) you need kernel accessible device > labels on each mirror device and log. The labels would track things > like: who's the primary, who's a slave, who's in the group, who's > failed, etc. I've seen some people advocate putting this in the log, > but the log can fail. (I hope I've already conveyed why I don't > think it's a good idea to mirror the log.) I don't have any good > ideas for making this happen right now. Yes, having a kernel accessible label on the mirror device would be best to handle these kinds of scenarios. Other possible option is to enhance log module to handle 'mirrored log' which can update log device failures in the log itself. Thanks, Malahal. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
