[dm-devel] BUG in dm/dm-mirror module?

[Jonathan Brassow]

On Aug 13, 2007, at 11:48 AM, Phillip Susi wrote:

> Jonathan Brassow wrote:
>> On a different topic, why are you mirroring the log?  Isn't this  
>> somewhat dangerous?
>> 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.
>
> This is a problem with any mirror, not just one holding a mirror log.

It is a special problem with the mirror log.

Mirrors will recover themselves and become consistent upon a reboot.   
In the case of a mirror that holds a file system, if you lost some of  
your most recent writes, journaling/fsck will take care of it.  In  
the case of a mirror that holds another mirror's log, you wind up  
with a log that does not contain recent data - and could spell  
coherency issues for the top level mirror.

>
>> You might argue that we should update the metadata to exclude the  
>> failed primary at the point of failure.  Two things come to mind:
>> 1) log I/O will continue until you take action - leaving you open  
>> to the scenario above
>> 2) it would be simpler to just allocate a new log (since you are  
>> changing metadata anyway) and initialize the log as "in-sync" if  
>> the mirror is already "in-sync".
>
> Yes, once one drive fails, the metadata on the other drive should  
> indicate that the mirror is broken and this is now the most up to  
> date copy.

There is no metadata on the other drive, that's part of the problem.   
We must discern between metadata that is made by LVM (or other  
userspace app) and meta-data areas that are known to the device  
mapper target.  Currently, the mirroring target only has the log  
device - which I contend is insufficient.

  brassow