[linux-lvm] Re: [LVM2 PATCH] mirror force resync option

Jonathan E Brassow jbrassow at redhat.com
Wed Oct 18 18:32:47 UTC 2006


On Oct 11, 2006, at 5:39 PM, Alasdair G Kergon wrote:

> On Wed, Oct 11, 2006 at 10:20:40AM -0500, Jon Brassow wrote:
>> I view
>> this as a bug in the 'deactivate_lv' code, since it should fail if
>> it is unable to deactivate the lv on all nodes.
>
> Correct, if that's true.  But the code doesn't show any deactivation
> attempt!  (see below)

Good spot.  I was incorrectly understanding the lv_info... line to 
identify active lv's on other machines.

>> +Enforce resynching the mirrored logical volumes.
>
> Needs explaining better here for someone who doesn't know
> what that means/involves:-)

Explanation expanded.

>
>> +	if (!(lv->status & MIRRORED))
>> +		return 1;
>
> Are you sure this shouldn't be an error?

I haven't changed this.  So, if tried on a linear volume, there would 
be no error (but nothing would be done).  This is easily changed if you 
like.

>
>> +	if (!lv_info(cmd, lv, &info, 0) || !info.exists)
>> +		active = 0;
>
> This is currently defined as telling you if the device is active on
> the local node.  (Patrick's looking at extending it to the cluster.)

right.

>
>> +	if (active) {
>> +		if (!deactivate_lv(cmd, lv)) {
>> +			log_error("Unable to deactivate, %s, for sync status change", 
>> lv->name);
>> +			log_error("Hint: %s may be in-use", lv->name);
>> +			return 0;
>> +		}
>
> On a cluster, you need to call deactivate_lv *even if* it's not active 
> on the
> local node.  So test for the VG clustered flag and use that to decide
> whether to do the lv_info/active test or not.  (That's only a local 
> optimisation
> normally to assist with the error messages.)

right

>
>> +		/* Must activate log, or we can't zero it */
>> +		if (!activate_lv(cmd, first_seg(lv)->log_lv)) {
>> +			log_error("Unable to activate, %s, for sync status change",
>> +				  first_seg(lv)->log_lv->name);
>> +			activate_lv(cmd, lv);
>> +			return 0;
>> +		}
>
> Interesting.   That extension to the interface needs more comment: you 
> need to
> demonstrate that the operation is either atomic (which it doesn't 
> appear to be
> at first sight), or else if it's not atomic, there must be no failure 
> modes
> that lead to corruption, or people thinking a complete resync got 
> forced when
> it actually didn't.
>
> Normally you're not allowed to activate only part of a device tree - 
> you can't
> activate a mirror log except as part of the mirror.   Notice how 
> lvcreate
> and lvconvert manipulate the log independently before attaching it to 
> the
> mirror.  However the recent changes to prepare for stacked devices 
> should be
> sufficient for that particular activation to work, so that's probably 
> acceptable
> now.
>
> A breakdown into atomic operations might be:
> Detach the log (leaving the [inactive] mirror with a core log), wipe 
> the log,
> then reattach it.
> Or you could introduce an additional metadata state to indicate the log
> needs to be wiped, wipe it, then revert to the previous metadata state.
> Or have a combination of both (so that a future lvchange -ay can 
> complete
> the process if interrupted).
>
>> +		/*
>> +		 * Note: there is no need to deactivate the log before
>> +		 * we activate the mirror
>> +		 */
>
> Because of the stacking preparation now, yes, so long as set_lv() 
> syncs the
> block device correctly.
>

Basically, I only added more to the man page and a check for CLUSTERED 
in tools/lvchange.c.  I've also added some comments in the patch as to 
why I believe the operation is atomic - posing no inconsistencies 
should the operation/machine fail while part way through.

  brassow

-------------- next part --------------
A non-text attachment was scrubbed...
Name: forcesync_mirror_option.patch
Type: application/octet-stream
Size: 7505 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20061018/0e010ccc/attachment.obj>
-------------- next part --------------



More information about the linux-lvm mailing list