Re: Re: [RFC] [PATCH] lvm2: mirroredlog support

[Stefan Raspl <raspl@linux.vnet.ibm.com>]

Hi Malahal,

malahal@us.ibm.com wrote:
>> Avoiding disk replication even if a log device got trouble is one of
>> the requirements. Is there any solution to avoid this problem by the
>> mirrored log approach?
> 
> Two ways to fix:
> 1) Never make "error leg" as your master leg as that is pointless.
> 2) Maybe we can use 'nosync' option when one of the two legs is known to
>    be an error device. This is probably easier than method (1)
> 
> Any other methods? Any help regarding which method to pursue would be
> very much appreciated.
> 
> Thanks, Malahal.
> PS: This patch was always used along with other patches and that could
> explain why we didn't notice this problem.

If I understand Takahiro correctly, the main issue is that the whole
log device becomes unusable in case one leg is broken...? Of course,
we still have the other leg with the most recent data available and
can read from that one. However, this would require that we can
start a mirror in rw-mode (so we can keep the still-recent half up
to date) even if one half has failed - a functionality which was
recently added to LVM, as we discussed in our last call...?
I'm not sure if I understand his statements about the
synchronization correctly. Why would any synchronization within the
data mirror occur at all? It's only the log which is broken, not the
actual data in vg00-lv00_mimage_0/1. If any synchronization in the
_data_ mirror occurs just because one leg in the _log_ mirror has a
problem, I'd consider that a bug.

Ciao,
Stefan

-- 
Linux on System z
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführer: Erich Baier
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294