[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] LVM mirror resync

Would it violate any principle to implement a third form of mirror
log, that would not require a 3rd device but still having the benefits
of keeping a persistent across reboots/crashes mirror status.

I'm thinking of a "internal" log (a la mdadm , HP-UX LVM, VXVM
mirroring, etc...)


2009/9/24 brem belguebli <brem belguebli gmail com>:
> 2009/9/24  <malahal us ibm com>:
>> brem belguebli [brem belguebli gmail com] wrote:
>>> My questions are:
>>> 1) Am I using the right method to simulate a drive failure by echoing
>>> a scsi delete ? How would behave the scsi layer in case a disk came to
>>> physically disappear ?
>> You are using a right method. You could pull the cables physically but
>> it is not going to make any difference to LVM mirror behaviour.
>>> 2) If the above method is correct, isn't the role of the mirror log to
>>> keep track of region changes  in case of a drive failure to be able to
>>> incrementally resync the mirror when the missing drive is back to
>>> operation?
>> Yes, but the implementation is not complete yet! Without the mirror
>> log (corelog), every reboot needs a complete resync. Mirror log is used
>> to avoid that but nothing more at this point!
>>>  Missing drive is not replaced, the UUID is the same, the problem
>>> could have occured at scsi connectivity not on the physical media (SAN
>>> failure for instance).
>>> 3) if so, why does disappear the log device from the VG though being
>>> on a physically present device ?
>> If you really look at your LV, it is no more a mirror. It is just a
>> linear LV! So your failed mirror leg as well as your mirror log are not
>> used. "dmeventd" will remove the failed mirror leg from the VG. It
>> probably removed the now unused mirror log also.
>>> 4) when the missing drive is back again,
>>>     4-1)  why does it appear as not belonging to its original VG ?
>> Because it was removed from the VG in the first place. The metadata on
>> other disks is the latest and is used.
> The VG information is still present on the "failed and back" disk. This could
> help the recovery process combined with next point to re assemble the mirror
> and to eventually do partial resync.
>>>     4-2) why doesn't it get automatically resync'ed by dmeventd ? .
>> It doesn't know any better! It doesn't know that it was a mirror.
> Keeping the log device in the VG wouldn't have helped it to keep track of this?
>>> The recover process seems to be to reconstruct from scratch the mirror
>>> treating the failed and back again drive as a totally new drive.
>> Yes! I heard that mdadm (raid1) can do (optimal resyncs) what you want
>> but I have no direct experience. You may want to try that if you need
>> this feature.
> Yes, I already use it. The setup is to configure an internal bitmap
> (log area) on
> your md array and it will do optimal resyncs in case of such a failure.
> The thing is that I am doing this on a cluster and mdadm is not
> naturally cluster aware.
> Mirror log relocation doesn't seem to be implemented yet / working either  .
> Regards

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]