Red Hat Bugzilla – Bug 149813
vgreducing while pvmoving causes inconsistency after pvmove completes
Last modified: 2007-11-30 17:11:00 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1 Description of problem: If you're freeing up multiple physical volumes, moving them to multiple other physical volumes, and you remove one of them from the volume group as soon as its pvmove completes, but before the other does, when the other completes, it will load a config file that brings back in the just-removed PV. If you've already done something else with that block device, the volume group goes missing one PV, wreaking havoc in, say, yet another pvmove operation running in parallel. Version-Release number of selected component (if applicable): lvm2-2.01.05-1.0 How reproducible: Didn't try Steps to Reproduce: 1.start two pvmoves in parallel, say from /dev/hda7 to /dev/sdb7 and from /dev/hda8 to /dev/sdb8. Run them in foreground, and arrange for the one that frees up say /dev/hda7 to complete first 2.as soon as the pvmove from hda7 completes, vgreduce it out of the VG, and immediately create another pv in there, such that the UUID changes 3.wait for the second pvmove to complete 4.run vgscan Actual Results: the volume group will report a missing PV Expected Results: pvmove shouldn't bring the removed PV back in Additional info:
Presumably a locking error somewhere. If you get the chance, please turn on full debug logging and repeat the test (eg to file or syslog in lvm.conf) and attach the output. Then we can check through it for any place that updates metadata while not holding the appropriate VG lock(s), or for somewhere that acquires a VG lock but uses an historic copy of the VG metadata instead of re-reading it after getting the lock.
It's also worth seeing if the 2.01.07 cache change makes any difference: if it's not a locking problem, it could be a uuid caching problem.
May well be related to 138396
A variety of cache improvements in 2.01.08 which I hope fixes this.
Assuming this is now fixed; reopen if not.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-192.html