In the event of a mirror leg being unavailable, CLVM mirror (RAID 1) needs to be able to recover without completely recopying the volume. It is acceptable that the volume is unavailable during this re-sync process.
In what way is the mirror leg "unavailable"? The current approach is to remove the disk. Are you asking to do nothing for a while, and then pick-up again when the device comes back? This will not be possible if the log device fails... it will be removed immediately, so the mirror can proceed. I can be quickly replaced though.
The request revolves around managing temporary connection outages without completely remirroring the volume. Given that there is no data transaction log, it would be "ok" to keep the mirror as unavailable while the dirty blocks are updated. This would mean that the mirror is either "valid" and usable or "not valid" and that there would be no point-in-time valid state.
not just a cluster mirror problem, but a mirror problem in general - switching components.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
One Usecase for this e.g. is planned datacentre outage. So if one datacentre is shut down, the mirrored LV could be rebuilt after a maintenance operation in the other datacentre.
Seems this request fits with this BZ. This is a two node cluster using HA-LVM. Request to have LVM mirror resync more inline with HP-UX a. If the mirror goes out of sync, the pv drops from the VG b. The VG becomes a linear volume c. And the entire PV has to be remirrored d In HP-UX the PV stays and each subsequent write gets logged aa. the admin can then say "ok, I replaced the disk" bb. even if he hadn't to force a rsync cc. and the resync is only partial then - only the stale extents Client would like to have this feauture request escalated. -Dave
This will likely not be implemented in RHEL 5, because it will be in a maintenance phase soon. I'm moving this feature request to upstream, it has to be implemented in upstream first, before backporting to RHEL.