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...) Regards 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 > _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
