From: malahal@us.ibm.com
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] alternative to pvmove on root volume
Date: Thu, 28 Jan 2010 13:17:20 -0800 [thread overview]
Message-ID: <20100128211720.GA23619@us.ibm.com> (raw)
In-Reply-To: <824411.76784.qm@web87113.mail.ird.yahoo.com>
chris procter [chris-procter@talk21.com] wrote:
> (resent, it didn't seem to come through last time)
>
> Hi,
>
> I'm trying to migrate our servers from an old EVA to a
> shiney new netapp san if possible without downtime. For most of the
> volumes I can present in luns from the new san and use pvmove to juggle
> the data around but several servers have the root volume on the EVA and
> pvmove has a nasty habit of deadlocking the machine when used on root
> volumes.
>
> I've been working on the technique mentioned on http://sources.redhat.com/lvm2/wiki/FrequentlyAskedQuestions but after a bit of thought it seems it might be better to do the following:
>
> 0) add /dev/new_lun to the volume group
> 1) lvconvert -m 1 /dev/myvg/lvol00 /dev/new_lun
> 2) wait for the mirror to sync
>
> now we have RAID1 mirror copy of lvol00 on /dev/old_lun and /dev/new_lun so:
>
> 3) lvconvert -m 0 /dev/myvg/lvol00 /dev/old_lun
> Breaks
> the RAID in favour of new_lun and gets rid of the old leaving us with a
> basic (non-mirrored) linear lvol entire on the new_lun.
>
> 4) Rinse and repeat for all the other lvols on old_lun (which you can get from "dmsetup table")
>
> 5) vgreduce myvg /dev/old_lun
>
>
> Its less elegant then pvmove but my initial testing seems to suggest it does actually work and doesn't cause deadlocks.
Have you tried pvmove for the same and found deadlocks? If not, your
test doesn't mean anything!
> However
> given that pvmove also works by mirroring I'm not convinced I haven't
> just been lucky so far . So does anyone have any ideas or even better
> experiance on whether this is likely to work or am I setting myself up
> for a world of pain if I try it on a live server?
Yes, pvmove works very similar. It will create a mirror for each segment
one at a time, so it may have to create lot more mirrors depending on
your configuration. If it ends up needing more 'lvconverts' (suspends),
then the probability of failure (deadlock) will increase.
--Malahal.
next prev parent reply other threads:[~2010-01-28 21:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 20:11 [linux-lvm] alternative to pvmove on root volume chris procter
2010-01-28 21:17 ` malahal [this message]
2010-01-29 13:28 ` Stuart D. Gathman
2010-01-29 18:39 ` chris procter
2010-01-29 9:21 ` Milan Broz
2010-01-29 18:26 ` chris procter
2010-01-29 18:50 ` Milan Broz
2010-01-29 21:18 ` chris procter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100128211720.GA23619@us.ibm.com \
--to=malahal@us.ibm.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).