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 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).