On 10/20/2011 03:47 PM, Bernd Broermann wrote:
CODE "move" script
# mirror
pvcreate /dev/disk2
vgextend vg01 /dev/disk2
lvconvert -m1 --mirrorlog core /dev/vg01/lvdata /dev/disk2
# split
lvconvert -m0 --mirrorlog core /dev/vg01/lvdata /dev/disk1
vgreduce vg01 /dev/disk1
pvremove /dev/disk1
If you just want to move the logical extents in vg01/lvdata from disk1
-> disk2 why not use pvmove?
Internally it will construct a corelog mirror in a very similar way but
it saves you from having to manually split things and supports
transactional updates allowing the move to be automatically resumed if
it is interrupted for any reason.
E.g.:
pvcreate /dev/disk2
pvmove /dev/disk1 /dev/disk2 (you can ommit disk2 here if it's the
only free space in the VG and pvmove will
chose it automatically)
vgreduce /dev/disk1
pvremove /dev/disk1
My assumption is that SLAVE reconfigures the device-mapper not correct,
when doing the "move" operations on MASTER.
Nothing told the SLAVE host that vg01/lvdata had changed so it still has
the original PV device open (from its point of view on that side of the
SRDF replication).
If the LV is not in use you can just de-activate/re-activate to have it
see the changes to the VG metadata:
vgchange -an vg01; vgchange -ay vg01
Unless you're using a clustered environment with clvmd hosts that have a
common view of shared storage will not be aware of on-disk changes made
by another host. This is hazardous if both hosts can write to the
storage at the same time as it's possible for simultaneous updates to
the VG metadata to corrupt one another (SRDF should prevent this since
only one side of the replicated device can be writable at a time but
some care is still needed to ensure all hosts have a coherent view of
the VG).
Regards,
Bryn.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
