From: "Bryn M. Reeves" <bmr@redhat.com>
To: maillists@conactive.com,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] shift PV from disk to raid device?
Date: Tue, 09 Dec 2008 14:24:49 +0000 [thread overview]
Message-ID: <493E7FB1.2090403@redhat.com> (raw)
In-Reply-To: <VA.000034ed.033a3e5f@news.conactive.com>
Kai Schaetzl wrote:
> Bryn M. Reeves wrote on Tue, 09 Dec 2008 10:30:54 +0000:
>
> I notice that I wrote "/dev/sda" where I should have written "/dev/sda3",
> of course. But I guess this doesn't make a difference.
>
>> pvmove
>
> thank you. I remember this command from reading the LVM how-to some months
> ago, but had forgotten by now. I had checked the pvchange command, but not
> this one. After reading man pvmove I'm not sure if using that would really
> be helpful. If I understand correctly using it will still copy a lot of
> data (all the data on the LVs). Basically it seems to move out all data
> from dev/sdan to a temporary lv, then move them back in to /dev/mdn. From
No, that's not correct. The pvmove command works entirely at the level
of PVs - no LVs involved and no temporary LVs are created. There is a
temporary mirror created between the source PV region and destination PV
region and this is then synced. Once the two regions are in sync, the
mirror is removed.
This is then repeated for each segment to be moved that is allocated on
the source PV. The operation is checkpointed after each segment, so if
there is a crash or sudden power failure the operation will
automatically re-start from the beginning of segment that was being
moved at the time of the failure.
> my non-expert view this might create a quite "unfavorable" data layout as
> it is all happening within the same "data location" on the disk. And all
It will use the same allocation policies as any LVM command. If you
don't like the default you can override it via the --alloc option or
specify explicit lists of destination PV ranges - see the man page.
> in all it might also take longer than a brute-force approach. I had hoped
Maybe, but it's a lot less likely to wreck your data. In practice, I've
rarely had performance problems with pvmove.
> there's some way to just move lvm metadata so that it knows it belongs to
> /dev/mdn and not /dev/sdan anymore.
No need. Once the pvmove has completed you can remove the (now unused)
source PV using the vgreduce command.
> So, I wonder if it isn't as good or even better if I do the following:
>
> - break the raid array md2
> (made from /dev/sda3 and /dev/sdb3 with duplicate PVs)
> - remove the PV on /dev/sda3
> - recreate it and all LVs on /dev/md2
> - copy over the data from the LVs on /dev/sdb3
Up to you, I have no experience doing it this way, but this is still
going to copy the same volume of data around. I also don't really
understand why you want to do all this if the data is already on md2.
Regards,
Bryn.
next prev parent reply other threads:[~2008-12-09 14:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-08 23:41 [linux-lvm] shift PV from disk to raid device? Kai Schaetzl
2008-12-09 10:30 ` Bryn M. Reeves
2008-12-09 13:09 ` Kai Schaetzl
2008-12-09 14:24 ` Bryn M. Reeves [this message]
2008-12-09 17:22 ` Kai Schaetzl
2008-12-09 16:54 ` Stuart D. Gathman
2008-12-09 16:56 ` Stuart D. Gathman
2008-12-09 17:36 ` Bryn M. Reeves
2008-12-09 18:16 ` Kai Schaetzl
2008-12-09 18:32 ` Kai Schaetzl
2008-12-09 18:03 ` Kai Schaetzl
2008-12-09 18:06 ` Bryn M. Reeves
2008-12-09 18:20 ` Kai Schaetzl
2008-12-09 18:38 ` Stuart D. Gathman
2008-12-09 19:42 ` Kai Schaetzl
2008-12-09 19:56 ` Doug Ledford
2008-12-09 20:15 ` Kai Schaetzl
2008-12-09 20:22 ` Doug Ledford
2008-12-09 21:03 ` Stuart D. Gathman
2008-12-09 21:22 ` Doug Ledford
2008-12-09 20:38 ` Kai Schaetzl
2008-12-09 20:51 ` Doug Ledford
2008-12-09 21:04 ` Stuart D. Gathman
2008-12-09 20:49 ` Kai Schaetzl
2008-12-09 20:56 ` Doug Ledford
2008-12-10 0:31 ` Kai Schaetzl
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=493E7FB1.2090403@redhat.com \
--to=bmr@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=maillists@conactive.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.