[linux-lvm] Move pvmove questions

[Stuart D Gathman]

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