All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.