mirror problem

[A.G.M. Velthof]

Hello to all,

we do have a weird problem.....

In the process of an lvreduce from a mirror lv to a 1 mirror lv, somebody wanted to perform that for half of the pvg.

The pvg exists of 16 disks and the lv is reduced with 8 disks.

The situation now is a 1 mirror lv spreaded of the 2 remaining pvg and 8 from the 16 disks of the pvg that had to be removed.

I cannot remove the remaining 8 disks of that pvg with lvreduce, because there is only 1 mirror left.

Anyone any idea how to solve this?

Regards, Alfons Velthof

[Torsten.]

IMHO the most safe solution is to mirror the LVOL again to the disks you want to keep, then remove the mirror from the disks you want to remove.

[A.G.M. Velthof]

Hello Torsten,

that is not an option here.

We have the situation of 3 pvg's and 1 mirror.

Regards, Alfons

[Torsten.]

3 PVG???

More details needed.

(vgdisplay, pvdisplay, lvdisplay, etc)

[Patrick Wallek]

>>More details needed.

Yes, please.  I really don't understand what the problem is.

[A.G.M. Velthof]

We are moving our data from 2 EVA's to 2 new F400 3PAR's and use hpux mirror for that.

The steps to do that are:

1. create disks on the 3PAR systems.

2. add the disks to the volume group

3. add the disks from 1 3PAR to the /etc/lvmpvg as a new pvg

4. lvextend [/dev/vgxxx/lvxxxx] -m 2 [new disks]

5. after syncing is compleet lvreduce [/dev/vgxxx/lvxxxx] -m 1 [old disks from 1 EVA

6. vgreduce [dev/vgxxx] [old disks from EVA]

then do the same trick for the other 3PAR and EVA, so we end up with 2 new 3PAR's in a mirror.

What went wrong here is:

We decided to do a lvreduce for not all the disks of the EVA, because there were to many disks for the commandline.

We got an error and now the situation is:

3 pvg's (EVA1, EVA2, 3PAR1)

1 mirror

So the mirror is located on 3 pvg's.

I cannot delete the remaining disks from the EVA with lvreduce because mirror is already 1

[Patrick Wallek]

The 'pvmove' command may be what you need.  That allows you to  move extents between disks.

If you can show use some vgdisplay and lvdisplay output from the LV, that may help.

[Dennis Handly]

>We are moving our data from 2 EVAs to 2 new F400 3PARs and use HP-UX mirror for that.

No peer motion available for 3.1.2 for that?

[A.G.M. Velthof]

I did apply a repost with attachment Yesterday, but it didn't show in the forum?

[Dennis Handly]

>I did apply a repost with attachment yesterday,

Did you give it a .txt suffix?

Please delete your last two giant posts and use the Post Options > Edit Reply to add the attachments to your first post.

[A.G.M. Velthof]

Hello Dennis

Thanks for putting me in the right direction.

First time I added an Attachment............

A vgdisplay and lvdisplay is added to my first Post.

Regards, Alfons

[Matti_Kurkela · Accepted solution]

So, to summarize:

You have a volume group with three PVGs named vgXXX_EVADC1, vgXXX_EVADC2 and vgXXX_3PARDC1.

The EVADC PVGs have 16 PVs each.

The 3PARDC1 PVG has only 4 PVs, but they seem to be much larger.

You have a number of LVs:

lvoracle: 28000 Mbytes, 3-way mirrored

lvsapmnt: 12000 Mbytes, 3-way mirrored

lvusrsap: 30000 Mbytes, 2-way mirrored

lvorigA: 4000 Mbytes, 3-way mirrored

lvmirrB: 4000 Mbytes, 3-way mirrored

lvorigB: 4000 Mbytes, 3-way mirrored

lvmirrA: 4000 Mbytes, 3-way mirrored

lvarch: 60000 Mbytes, 3-way mirrored

lvdata1: 320000 Mbytes, 2-way mirrored

lvdata2: 320000 Mbytes, 2-way mirrored

lvdata3: 350000 Mbytes, 2-way mirrored

The "Mirror copies" value in LV status can be confusing: "Mirror copies 1" means "original and 1 copy". Each LV has a separate "Mirror copies" value, so many of your LVs are still 3-way mirrored. An alternate way of verifying this is to look at the number of LEs vs. PEs allocated to each LV: 

• if number of PEs = number of LEs, the LV is not mirrored at all ("Mirror copies 0")
• if number of PEs = 2* number of LEs, the LV is 2-way mirrored ("Mirror copies 1" or original + 1 copy)
• if number of PEs = 3* number of LEs, the LV is 3-way mirrored ("Mirror copies 2" or original + 2 copies)

The attachment included the full logical volume information of the lvusrsap LV only, and it seems to have a PVG-strict allocation policy.

If you cannot reduce the mirroring any further even temporarily, you can use pvmove to move one of the two copies of each extent to a different PVG. For example, this would migrate all the parts of lvusrsap that are still on vgXXX_EVADC1 to vgXXX_3PARDC1:

#!/bin/sh
# the line below lists the numbers of all vgXXX_EVADC1 PVs that contain data for lvusrsap: 
for i in 404 409 410 498 503 508 512
do
    pvmove -n /dev/vgXXX/lvusrsap /dev/disk/$i vgXXX_3PARDC1
done

 (Looking quickly through the lvdisplay -v output, the lvusrsap LV seem to be partly mirrored EVADC2 <-> 3PARDC1 and partly EVADC1 <-> EVADC2. This script would push the parts that still remain on EVADC1 to 3PARDC1 instead.)

Manipulating the mirror components this way might be easier, as you have a large number of PVs.

I assume that you are planning to migrate one copy of the data to 3PARDC1 before removing one of the EVAs and installing 3PARDC2 in its place.

[A.G.M. Velthof]

Thanks for explaining.

Yesterday I decided to create a temporary VG on new disks and copied all data to it.

I removed the "old" VG and created a new one with the same name (it is a MCSG) and 1 mirror.

Moved the data back and now it is completely running on the 2 new storage systems.

Thanks for the Time......

Regards, Alfons

[Matti_Kurkela]

Considering that moving the old VG as it was to the new storage might have caused the extents to be in a somewhat random order, this was probably a good thing.

The extents won't *have* to be in any particular order, but if they are, it guarantees that sequential operations (like backing up your database) will be easily detected as such by the storage system, and it can apply prefetching and other strategies to improve performance. If the extents are in randomized order, a multi-extent sequential operation at the filesystem layer gets translated to jumping all over the place, which would be harder for the storage system to optimize.

Creating a new VG with a new filesystem and copying your data to it is also a simple way to eliminate all filesystem-level fragmentation, if it exists.

I hope you used this as an opportunity to re-evaluate your VG parameters too, although the parameters of your old VG didn't look too bad to me either (assuming that the VG Max Size is enough for your expected growth).