FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 10-20-2011, 02:47 PM
"Bernd Broermann"
 
Default DM inconsistent after disk migration

Hallo

I can not remove an unused LUN , because devicemapper is inconsistent
under /sys/block.

Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Linux xxxxxxx 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux
device-mapper-multipath-0.4.7-34.el5


we have two hosts (MASTER,SLAVE) , which are connected to a shared storage
(EMC SAN and SRDF) with two equal sized disks.
One of the disk contains a Logical Volume in one Volume Group.

we wanted to migrate ("move") data from disk1 to disk2 , and remove disk1
afterwards.


MASTER SLAVE
disk1 (vg01/lvdata) <-srdf-> disk3 (vg01/lvdata)
disk2 (empty) <-srdf-> disk4 (empty)

On MASTER we "move" disk1 to disk2 with following commands.
Because of the SRDF mirror disk3 is copied simultaneous to disk4.



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


The "move" process runs without error.
On MASTER disk1 can be removed without error.
On SLAVE removing disk3 gives an error like

powermt remove dev=disk3
Cannot remove device that is in use: disk3
( in real /dev/disk3 is /dev/emcpower$(belonging disk3 )


i analyzed the /sys filesystem on SLAVE and saw , that vg01-lvdata is
blocks by /dev/disk3.


find /sys -name '*disk3*' -ls
29486 0 lrwxrwxrwx 1 root root 0 Jul 27 09:10
/sys/block/dm-9/slaves/disk3 -> ../../../block/disk3
ls -l /dev/mapper/vg01-lvdata
brw-rw---- 1 root disk 253, 9 Jul 27 09:09 /dev/mapper/vg01-lvdata

My assumption is that SLAVE reconfigures the device-mapper not correct,
when doing the "move" operations on MASTER.

How can I reconfigure the device-mapper stuff on SLAVE to avoid an reboot ?


A bit complex, but i hope i could make the problem clear to you.

regards
bernd

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 10-20-2011, 03:09 PM
"Bryn M. Reeves"
 
Default 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.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 10-28-2011, 02:06 PM
Bernd Broermann
 
Default DM inconsistent after disk migration

Am 20.10.2011 17:09, schrieb 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

Thank you,
you gave me the right advice.

I did a vgchange --refresh , as senn in the man page.
Other dead entries of LVs on SLAVE , I could remove with "dmsetup remove <LV device>".

Bernd

>
> 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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 01:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org