Bug 319221

Summary:	Incrementally remirror due to temperally unavailable mirror legs
Product:	[Fedora] Fedora	Reporter:	Scott Crenshaw <crenshaw>
Component:	lvm2	Assignee:	Jonathan Earl Brassow <jbrassow>
Status:	CLOSED DUPLICATE	QA Contact:	Cluster QE <mspqa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	rawhide	CC:	agk, bmarzins, bmr, dsulliva, dwysocha, fbijlsma, heinzm, jbrassow, jonathan, lvm-team, mbroz, mpatocka, msnitzer, prajnoha, prockai, ra
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-05-18 18:15:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rob Kenna 2007-10-04 20:29:10 UTC

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.

Comment 2 Jonathan Earl Brassow 2008-02-13 21:24:30 UTC

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.

Comment 3 Rob Kenna 2008-02-28 15:22:40 UTC

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.

Comment 4 Jonathan Earl Brassow 2008-04-02 21:52:16 UTC

not just a cluster mirror problem, but a mirror problem in general - switching
components.

Comment 7 RHEL Program Management 2008-10-27 18:22:13 UTC

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.

Comment 8 Frederik Bijlsma 2008-12-01 22:24:42 UTC

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.

Comment 12 Dave Sullivan 2010-04-27 00:27:38 UTC

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

Comment 13 Mikuláš Patočka 2010-04-28 14:31:13 UTC

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.