Bug 193330 - pvmove cannot move root fs
pvmove cannot move root fs
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
10
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-27 10:41 EDT by Dan Horák
Modified: 2009-12-18 06:00 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:52:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Horák 2006-05-27 10:41:02 EDT
I have problems problems with moving the root filesystem from a PV on a
partition to a PV on degraded mirror. When running "pvmove -v /dev/sda2
/dev/md1", it displays a few messages ending with
    Found volume group "VolGroup00"
    Loading VolGroup00-pvmove0
and the whole system is got stuck (I can type some characters, switch between
consoles (Alt+Fx) and after (probably) trying to open a file (first I wanted to
log in on other console, then I was opening a file in Midnight Commander) there
is an end, no input possible)

I found probably the same behaviour in a messages at
http://www.redhat.com/archives/linux-lvm/2004-December/msg00007.html

After powering the machine off and back on, the disks start working and after a
while the move is completed.


kernel-2.6.16-1.2111_FC4smp
lvm2-2.01.08-2.1
Comment 1 Dan Horák 2006-05-27 10:42:30 EDT
I was moving 4 other LV (3 filesystems and 1 with swap) from the same PV too and
there was no problem.
Comment 2 Christian Iseli 2007-01-22 05:17:39 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 3 Dan Horák 2007-01-22 05:40:08 EST
I am not able to test the issue in current Fedora (or RHEL), so I am closing it.
Comment 4 Patrick C. F. Ernzer 2008-11-28 07:22:37 EST
Same problem in F10 yesterday.

Two questions on this:
  1) is moving the currently active rootfs even supposed to work?
  2) could it be that being more patient is required?

Esp on 2), as I know that a pvmove will just continue after interruption and I wanted my box back ASAP yesterday, I just shrugged after 15 seconds of extreme sluggishness, reset the box, booted rescue to finish the pvmove and brough the box back up.

If you can confirm that the answr to both is yes I can retest (on different hardware though) and just let it run overnight. And I may be able to retest on the same hardware but in a different direction (had to move my LVs temporarily off the box, will move them back at some point)
Comment 5 Milan Broz 2008-11-28 07:50:37 EST
Moving of rootfs should bacically work.

But it can be problematic is some situations, the safest way it run the move from rescue disc, not from rootsystems itself.

But maybe just new problem appeared, not too much info to check it here.
(If you see that it stucks, we need at least output of "echo t >/proc/sysrq-trigger", "dmsetup status --noopencount" and ideally debug output of "pvmove -vvvv <params>"  to see whats' happening.)

Anyway, there were some reports of pvmove speed problems, not sure it this is the problem here.

Btw 15 seconds is default check interval (see -i option), pvmove basically just monitors progress and in specified time intervals update metadata mappings, the real transfer run in kernel.
Comment 6 Heinz Mauelshagen 2008-11-28 07:53:38 EST
for the record: 471042 is the cluster pvmove regression
Comment 7 Patrick C. F. Ernzer 2008-11-30 16:01:43 EST
doh! it just dawned on me that the PV I moved the data from also had the LV for swap on it. Could that have been the problem?

Did another pvmove (back from the external temporary disk to the internal drives), but disabled swap (swapoff -a, I have 8GB RAM on this box, so it's no problem to swith the 2GB swapp off temporarily) and that went just fine.
Comment 8 Dan Horák 2009-01-28 07:34:42 EST
I have just successfully moved my / to another PV. It was done from runlevel 1 and all other filesystems were unmounted, swap was enabled.


lvm2-2.02.39-7.fc10.x86_64
kernel-2.6.27.12-170.2.5.fc10.x86_64
Comment 9 Patrick C. F. Ernzer 2009-01-28 07:58:51 EST
Dan, did you only move the LV / or a whole PV that contained / and swap?
In case of the latter I think we can close this (bug owner will decide), in case of the former we may want to just make a note in the man page to not move the swap LV
Comment 10 Dan Horák 2009-01-28 08:10:52 EST
I moved all LVs stored on the PV manually (including the swap) with "pvmove -n <name-of-lv> /dev/source /dev/destination", only the "/" was moved in runlevel 1.
Comment 11 Mikulas Patocka 2009-01-28 22:47:17 EST
Please, anyone who can reproduce this bug, try it and when the computer locks up, press Alt+SysRq+W. Copy the result and paste it here.
Comment 12 Bug Zapper 2009-11-18 03:06:45 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Bug Zapper 2009-12-18 00:52:22 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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