[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] DM inconsistent after disk migration



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]