Bug 319221 - Incrementally remirror due to temperally unavailable mirror legs
Summary: Incrementally remirror due to temperally unavailable mirror legs
Status: CLOSED DUPLICATE of bug 593119
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jonathan Earl Brassow
QA Contact: Cluster QE
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-04 20:29 UTC by Scott Crenshaw
Modified: 2010-05-18 18:15 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-18 18:15:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

Comment 7 RHEL Product and 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.


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.

Note You need to log in before you can comment on or make changes to this bug.