LVM Mirroring Issue

[Sundar_7]

Dear All,,

Here is one interesting issue for U geeks..

Problem :

In one of the machine that I maintain,,

the /opt file System is 175 * 4 MB big..

and it is mirrored..

But the issue is that,,we are having PVG

in PVGPM

/dev/dsk/c100t6d0

/dev/dsk/c100t5d0

in PVGMI

/dev/dsk/c101t5d0

/dev/dsk/c101t6d0

and for some reason or the other when the

LV is mirrored,,PVG Strict allocation

is not enforced and the mirror copy

fallen in the same PVG group..

that is the mirror copy of

/dev/dsk/c100t6d0 is there in part in

/dev/dsk/c100t5d0 (SAME PVG) and in part in

/dev/dsk/c101t6d0..

and this issue came in to limelight recently

and I was assigned the task of remirroing

the LV with PVG strict allocation enforced..

I did it by splitting the mirror copy then

removing the mirror copy,enforcing PVG strict

and then re-mirroing the LV..

I DOCUMENTED THIS ALSO..AND PLEASE FIND THE

DOC FILE ATTACHED..

Everything went fine..

But now the problem is that one of my manager

is issuing concern over the steps I followed

He says lvsplit method is not recommended by

HP..

I know the same thing can be done by first

lvreducing the mirror and then re-mirroring the

LV.

But I found the previous method safer one..

As I dont have any proof that the method that

I followed is the safer one,,I could not

justify my steps..

So if U geeks can go through the

procedures in the DOC file and let me know

which is the safest method to do this also

whether I am correct or not..

Thanks and waiting to hear from U all

Sundar

[Stefan Farrelly]

I agree, dont use the lvsplit method. The lvreduce -m 0 and then re-mirroring later is preferred. Thats what I would use.

Have you investigated using pvmove to move the lvols to the disks you want on-the-fly without needing to reduce ? then enforce PVG strict ? I would try that first as its minimal risk.

[Pedro Sousa]

Hi Sundar!

Both methods you presented are OK and safe.
Although, method 1 is faster than the 2nd :).

I would only change 'step 4' to:
lvextend -m 1 /dev/vg00/lvol5 PVGMI

Cause, since you're using "-s g" option, you can only specify the PVG instead of the PV.

You can test if your allocation policy is correct by trying extending the lvol to the same disk where it resides:
lvextend -m 2 /dev/vg00/lvol5 PVGPM

if it doesn't succeed, then it's ok, bu if it does... well... check it first, OK? :)

good luck.

[Sundar_7]

Thanks Mr.Stephan,

But I thought U will get in my way..

Can U please let me know what will be the

risk if we go for lvsplit method..

I thought that will be the better option..

Clear me please

Sundar

[Thierry Poels_1]

Hi,
I don't see any reason why lvsplit shouldn't be used.
lvsplit gives you an extra backup, if, and only IF you keep the split lvol. If you split and immediately lvremove the split lvol then I can't see any advantage of using the lvsplit method.
Another safe way is to add an extra mirror on the correct disk(s) and then remove the "wrong" mirror.
regards,
Thierry.

[James R. Ferguson]

Hi Sundar:

I'd choose the first method, starting with the 'lvreduce', as this is the most direct. I don't think you are gaining much "protection" by choosing method-2 which begins with a 'lvsplit'. The time to complete either method is very short, and the probability of something going wrong with the primary disk during that time is very, very small.

In addtition, the extra 'vgsync' is superflous, as you indicated. Checking the recomposed volume group for stale extents with 'lvdisplay' is quite sufficient for confirmation, in my opinion.

...JRF...

[Shahul]

Hi

U are right. If I am in ur position I would have done the same. But first I would have tried this.

#pvmove /dev/dsk/c100t5d0 PVGM1

But then also U can't enforce the strict allocation policy. Because in a mirrored lvol U can't enforce strict policy.

Best of luck

Shahul