<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 June 2015 at 18:49, bascule <span dir="ltr"><<a href="mailto:asura@theexcession.co.uk" target="_blank">asura@theexcession.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tuesday 02 Jun 2015 06:58:20 Neil Greenwood wrote:<br>
> If they are in the same logical volume, it's more difficult.<br>
><br>
> There are some low-level LVM commands that do it, but normally with LVM you<br>
> should just forget where your data is actually stored. I did it once to<br>
> move some data from a mechanical disk to a SSD. It's much easier if they<br>
> are separate volume groups though...<br>
><br>
><br>
> Neil<br>
</span>ok, so if a make the second disk a different logical volume then i can use<br>
pmove as Matt suggests? am i right in thinking that with lvm i no longer have<br>
to worry about the order that hard drives are plugged into the motherboard and<br>
which disk is sda versus sdb/c etc in fstab?<br></blockquote><div><br></div><div>Add the PV (physical volume) to the same VG (volume group) the you can migrate the physical extents using pvmove.  </div><div><br></div><div>The structure of LVM is that PVs (typically disks or partitions - often a single partition that spans an entire disk) belong to VGs (volume groups). VGs are a collection of PVs and the LVs (logical volumes), sit on the PVs in the same VG. This allows striped LVs and mirrored LVs in the same VG for example. <a href="http://commons.wikimedia.org/wiki/File:Lvm.svg">http://commons.wikimedia.org/wiki/File:Lvm.svg</a> is worth studying to see how these blocks interrelate. </div><div><br></div><div>LVM is extremely powerful and is been constantly improved (mostly by Red Hat, is seems).</div><div><br></div><div>HTH,</div><div>Matt</div></div></div></div>