[dm-devel] DM inconsistent after disk migration

[Bryn M. Reeves]

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.