|Summary:||pvmove locks and becomes unkillable potentially corrupting volumes|
|Product:||[Fedora] Fedora||Reporter:||Andrew Meredith <andrew>|
|Component:||lvm2||Assignee:||Alasdair Kergon <agk>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-08-18 17:03:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Andrew Meredith 2004-07-30 12:59:39 UTC
Description of problem: when trying to move lvm2 data off a drive prior to removal/replacement, the use of pvmove locks and potentially corrupts the volume group. See https://www.redhat.com/archives/linux-lvm/2004-June/msg00066.html Version-Release number of selected component (if applicable): lvm2-2.00.15-2 kernel-2.6.6-1.435.2.3 How reproducible: Sadly, 100% Steps to Reproduce: 1. Create lvm2 vg with more than one PV 2. pvmove one of the PVs Actual results: Locked pvmove process. If you try pvmove --abort, that locks too. Expected results: The data moving off the PV Additional info: Although things look quite bad, I have not actually lost any data as yet. One may need to reboot a couple of times with a "pvmove --abort" in the first reboot, but all is not lost .. it just looks that way.
Comment 1 Alasdair Kergon 2004-08-12 16:01:13 UTC
(a) don't know if that kernel included mirror support (needed by pvmove) or not: the newest kernels do and newer lvm2 RPMs check for this before initiating the pvmove; (b) you shouldn't try to pvmove a system volume (containing /etc, /dev, /var etc.) as pvmove itself needs to access those directories (probably need to run with everything lvm2 uses in a ramdisk instead to make this work).
Comment 2 Andrew Meredith 2004-08-13 01:16:29 UTC
In answer .. a) How can this be checked for? The last pvmove I did nearly lead to the loss of quite a lot of data (as mentioned) and therefore restore time. I would like to check for this before trying again. b) The system in question had two VGs. One was for system stuff and the other purely data. The pvmove was attempted in the vgdata volume.
Comment 3 Alasdair Kergon 2004-08-18 17:02:41 UTC
(a) checks were added in 2.00.16. pvmove uses a mirror to move the data so it won't free up the original data location until the data is already synced into its new location. So (b) doesn't apply in your case
Comment 4 Michael T. Babcock 2004-09-19 18:29:47 UTC
I've just had the same problem -- pvmove locked hard at about 98% of a 10GB pvmove. dm-mirror seemed happy until I started getting memory pressure-like kernel errors when checking dmesg. pvmove never finished. I force-sync'd the drives and rebooted with SysRq-U,S,B since nothing else was working anymore (I could type commands, but nothing actually happened). On reboot, pvmove appeared to try and continue but failed again the same way. I rebooted into runlevel 1 and did an --abort but that did 'nothing' as well. I finally moved the dm-mirror module into /tmp/ to force it to not continue and that worked (I'm running right now) but two of my logical volumes are corrupt; I'm assuming the mirrored version is correct, somehow. How do I get my data? :-)