From: Stuart D Gathman <stuart@bmsi.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Move pvmove questions
Date: Tue, 18 Jan 2011 13:35:33 -0500 [thread overview]
Message-ID: <4D35DD75.2090401@bmsi.com> (raw)
In-Reply-To: <AANLkTi=2R_wHqquR1ZhAdRdH3sxke6vg0Auzqy0MDtm_@mail.gmail.com>
I see the man page has been expanded into steps already. I added what I
think are helpful amplifications. What do
you think? See the original man page reader complaint below.
diff -u -r1.3 pvmove.8.in
--- pvmove.8.in 4 Aug 2009 08:09:52 -0000 1.3
+++ pvmove.8.in 18 Jan 2011 18:30:16 -0000
@@ -40,14 +40,18 @@
details of all the data movements required.
2. Every logical volume in the volume group is searched
-for contiguous data that need moving
-according to the command line arguments.
-For each piece of data found, a new segment is added to the end of the
-pvmove LV.
+for PEs that need moving according to the command line arguments. These PEs
+are divided into "segments", runs of physically contiguous data where the PEs
+are adjacent on a PV. For each such run of data found, a new segment is added
+to the end of the pvmove LV.
This segment takes the form of a temporary mirror to copy the data
-from the original location to a newly-allocated location.
+from the original location to a newly-allocated location. A temporary
+mirror is marked as such in the on disk metadata so that system knows now to
+finish or undo the pvmove in the event it is interrupted by a system crash.
The original LV is updated to use the new temporary mirror segment
-in the pvmove LV instead of accessing the data directly.
+in the pvmove LV instead of accessing the data directly, so that any writes
+to the original LV are written to both segments until the temporary mirror
+is syncronized.
3. The volume group metadata is updated on disk.
@@ -58,7 +62,8 @@
5. A daemon repeatedly checks progress at the specified time interval.
When it detects that the first temporary mirror is in-sync,
it breaks that mirror so that only the new location for that data gets used
-and writes a checkpoint into the volume group metadata on disk.
+and writes a checkpoint into the volume group metadata on disk, so that
+the step isn't repeated in the event of a system crash.
Then it activates the mirror for the next segment of the pvmove LV.
6. When there are no more segments left to be mirrored,
On 11/18/2010 05:06 PM, Stirling Westrup wrote:
> On Thu, Nov 18, 2010 at 4:32 PM, Alasdair G Kergon <agk@redhat.com> wrote:
>> On Thu, Nov 18, 2010 at 03:40:25PM -0500, Stirling Westrup wrote:
>>> It mentions checkpointing, but gives no further information. It
>>> certainly doesn't say anything about how often they are done, or under
>>> what circumstances.
>> It's in there, but the man page would indeed benefit from more repetition
>> and examples. Patches welcome!
>>
>> Every logical volume in the volume group is searched for *contiguous
>> data* that need moving according to the command line arguments. For
>> each piece of data found, a new *segment* is added to the end of the
>> pvmove LV. This segment takes the form of a *temporary mirror* to copy
>> the data from the original location to a newly-allocated location.
>>
>> A daemon repeatedly checks progress at the specified time interval.
>> When it detects that the first *temporary mirror* is in-sync, it breaks
>> that mirror so that only the new location for that data gets used and
>> writes a *checkpoint* into the volume group metadata on disk.
>>
>> So checkpoint at first daemon check interval after temp mirror in-sync, and
>> one temp mirror per item of contiguous data to be moved.
> The interpretation you give is only possible if one knows what the
> man-page writer means by 'contiguous data', 'segment' and 'temporary
> mirror'. As it was, I didn't and spent some time perusing the man
> pages to find anywhere where these terms are defined, with no luck.
>
> So, yes, the man page definitely needs fixing. And that, perhaps,
> should be done by someone who has a heck of a lot more familiarity
> with the system than I have, or else the resulting man page is likely
> to end up BOTH inadequate and erroneous.
>
> Still, I submit that if the man page needs to talk about checkpoints
> AT ALL, then there needs to be a user method for determining, the
> status of checkpoints during a pvmove.
next prev parent reply other threads:[~2011-01-18 18:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 19:53 [linux-lvm] Move pvmove questions Was: Need help with a particular use-case for pvmove Stirling Westrup
2010-11-15 21:47 ` Lars Ellenberg
2010-11-15 22:27 ` Stirling Westrup
2010-11-15 23:21 ` Stuart D. Gathman
2010-11-16 6:25 ` Luca Berra
2010-11-18 18:30 ` Stirling Westrup
2010-11-18 20:12 ` Alasdair G Kergon
2010-11-18 20:40 ` Stirling Westrup
2010-11-18 21:32 ` Alasdair G Kergon
2010-11-18 22:06 ` Stirling Westrup
2011-01-18 18:35 ` Stuart D Gathman [this message]
2010-11-19 21:56 ` Stuart D. Gathman
2010-11-19 22:25 ` Stirling Westrup
2010-11-21 14:17 ` Sven Eschenberg
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=4D35DD75.2090401@bmsi.com \
--to=stuart@bmsi.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 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.