pvmove & performance improving

[Victor_5]

Just FYI...

Question:
I'm trying to understand LVM's pvmove command. A colleague wants to use it to move extents to improve i/o performance in a VG. I think this might be ok in the short term, but pvmove is really meant for restoring data to a repaired drive. Are we both wrong/right?

Answer:
The pvmove command lets you move extends from one PV (physical volume, ie disk) in a VG (volume group) to another PV in the same VG. It isn't particularly granular, so you can't move just one PE (physical extent), and you can't even move some of them. You have to move them a whole LV (logical volume) at a time.

It can be used for i/o performance reasons. For example, if you had a slow drive and wanted to move a logical volume from it to a
faster disk, you could add the faster disk to the same VG and pvmove the lvol onto the new disk.

As for restoring data to a repaired disk, I'm not sure why you'd use this tool. I deal almost exclusively with mirrored disks (mirror/ux),
and that includes facilities for replacing drives and migrating the data back where it belongs.

For the truly creative, you could use pvmove and a 'scratch' disk to re-order the sequence of lvols on a PV, or to make them
contiguous again if you had some several extends.

As always, I'd recomend you come to the most current patch rev so that pvmove does what is described in the man pages, rather than what it actually did when the OS was first released.

By David Hixson, he is an HP-UX system administrator providing customer service support for the clients of a major telecommuncations equipment provider. He provides support for fault-tolerant systems to respond to outages and assists in building high availability configurations. LVM and mirror/UX play a particularly important role in providing the required levels of availability. In addition to LVM, David performs general system administration tasks and core dump analysis.

[Todd Lehr]

I've always used lvextend and lvreduce to do these sorts of activities. It was much more comforting to see the new lvol copy working before reducing the original out. I also figured more people used lvextend/lvreduce and thus (hopefully) it was more stable/patched/updated than pvmove.

Even in situations where I had a bad disk, I would lvextend the good lvols onto another disk and then reduce them off the bad disk rather than just using pvmove.

Having said that, this is definately a good way to move around lvols to improve performance, however I just prefered the alternate method.

[Sandip Ghosh]

Another utility of pvmove is disk consolidation. Suppose you have 70-80 logical volumes in a VG in scattered way. After few days you have removed some of the lvs and you need to take out some disks from that particular VG. At that time pvmove is very effective.

Sandip

[Joaquin Gil de Vergara]

I use pvmove many times to reorganize my customer's VGs

It works fine and you can run it without stop system securely

Is an excelent LVM tool

[Martin Johnson]

I perfer mirroring over pvmovev, if the disk space is available. Mirroring is about 3 times faster. When you are moving GBs of data, mirroring saves a lot of time.

HTH
Marty

[Joaquin Gil de Vergara]

yes, mirror it's faster...

but with pvmove you can move one entire disk to another without worring about LV contained in it... in the destination disk this LV will be contiguous..... (only the part that is in source disk of course... if LV extends along some PVs, only PEs in source disk will be moved to dest disk)

if you work at LV level mirroring is better... I agree..

[KapilRaj]

I use pvmove ,

01. Need to take out one disk to allocate it to another vg.
--Move all the pe's from that disk to other disks , vgreduce the disk, pvcreate,vgcreate/extend

02. improve performance as others stated. move pe's to a faster disk.

03. Preventive action ie. if a disk is about to fail shift all pe's from that to another disk /disks.

04. wanna mirror a logical volume which is striped.

-- move pe's of that lvol from all the disks to a single disk , lvchange , lvextend -m

Correct me where i am wrong

kaps