HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

LVREDUCE

 
SOLVED
Go to solution
GPissutto
Frequent Advisor

LVREDUCE

Hello everyone,
I have dicovered that a mirrored LVOL between two storage array is actually misconfigured, it means that some parts of the mirror are in one array (the PV1 and PV2 columns), so if one of the array fails, everything fails. This LVOL is created from multiple PVOLs (16 for one array and other 16 for the second array). So I created a second mirror copy in one of the array in order to fix this problem. The thing is that I want to fix this properly and eliminate those misconfigured LEs pointing to the same PV. If I erased those 32 misconfigured PVs, lefting only those 16 new which I am sure are good. After lvreduce, is it everything to be operational?. I've tryed with a small lab and it works, but doing it live for a production system is something else...

Thanks very much for any hint.
9 REPLIES
R.O.
Esteemed Contributor

Re: LVREDUCE

Hi,

You should have no problems, but to be sure it would be good that you attached the output of "lvdisplay -v /dev/vgXX/lvolX"

Regards,
"When you look into an abyss, the abyss also looks into you"
GPissutto
Frequent Advisor

Re: LVREDUCE

Thanks R.O, here is the output. Check from disk213 on.

rariasn
Honored Contributor

Re: LVREDUCE

Hi GPissuto,

lvreduce -m 1 /dev/vgsapdata1_p/lvsapdata1 /dev/dsk/cxtydz

rgs,
R.O.
Esteemed Contributor
Solution

Re: LVREDUCE

Hi,

You have the mirror not well configured. The logical volume has "Allocation non-strict" and this means that mirrors of a logical extent can share the same physical volume, as you can see:


--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2 PV3 PE3 Status 3
06398 /dev/disk/disk213 00000 current /dev/disk/disk213 00001 current /dev/disk/disk298 00000 current


This happens from disk213 on. As you have two mirrors, you should "lvreduce" disks of the two firsts columns. After that, you should change the logical volume allocation policy to "strict" and redo the mirror.

# lvreduce -m 1 /dev/vgsapdata1_p/lvsapdata1
# lvchange -s y /dev/vgsapdata1_p/lvsapdata1

And then, redo the mirror with the proper disks. Maybe you want confirmation of this procedure from other forum experts.

Regards,
"When you look into an abyss, the abyss also looks into you"
GPissutto
Frequent Advisor

Re: LVREDUCE

Yes, I noticed all that and that's why I need to fix everything. I tryed fixing it in small lab with 6 LUN (1G each) and it worked fine when I reduced the two first columns at once, but not that well if I reduced one by one. So, as you can see there are many PVs involved and I wanted some other opinion to get couraged.

Thanks very much.
GPissutto
Frequent Advisor

Re: LVREDUCE

Anothe thing R.O, did you mean:
# lvreduce -m 0 /dev/vgsapdata1_p/lvsapdata1 ?

Cause leaving a mirror copy is the scenario that doesn't work well.
R.O.
Esteemed Contributor

Re: LVREDUCE

Yes, sorry for that. I mean "-m 0", because you don't want any mirror copy. You have to be sure of including all the pvs of the two first columns in the lvreduce command.

Regards,
"When you look into an abyss, the abyss also looks into you"
singh sanjeev
Trusted Contributor

Re: LVREDUCE

best is to do via pvmove command :

move the LV from one array to deired array..
Sanjeev Singh
GPissutto
Frequent Advisor

Re: LVREDUCE

Thanks