AIX 5.3: Warning - logical volume fslv00 may be partially mirrored

[Database Administrator]

Good day, everyone.

Accidentally I found out that there is a potential problem on one of our AIX
boxes in rootvg. When displaying LVs in a VG, following warning message issued
for one of LVs:

# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/syncd N/A
[...skipped...]
loglv00 jfs2log 1 1 1 open/syncd N/A
0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
fslv00 jfs2 58 106 3 open/syncd /app

I presume this happened when I was extending the '/app' filesystem some time ago
using 'smit chfs' menu. Not exactly sure how it happened, but the result is:

# lspv -l hdisk0
hdisk0:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
hd2 14 14 00..00..14..00..00 /usr
fslv00 48 48 00..48..00..00..00 /app
......

# lspv -l hdisk1
hdisk1:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
hd2 14 14 00..00..14..00..00 /usr
fslv00 58 58 00..58..00..00..00 /app
......

So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.

Is there a way to 'fully mirror' this LV without backing up/removing filesystem
and LV, then re-creating and restoring?

Alex

[Database Administrator]

AlexB a écrit :
> Good day, everyone.
>
> Accidentally I found out that there is a potential problem on one of our AIX
> boxes in rootvg. When displaying LVs in a VG, following warning message issued
> for one of LVs:
>
> # lsvg -l rootvg
> rootvg:
> LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
> hd5 boot 1 2 2 closed/syncd N/A
> [...skipped...]
> loglv00 jfs2log 1 1 1 open/syncd N/A
> 0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
> fslv00 jfs2 58 106 3 open/syncd /app
>
> I presume this happened when I was extending the '/app' filesystem some time ago
> using 'smit chfs' menu. Not exactly sure how it happened, but the result is:
>
> # lspv -l hdisk0
> hdisk0:
> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
> hd2 14 14 00..00..14..00..00 /usr
> fslv00 48 48 00..48..00..00..00 /app
> .....
>
> # lspv -l hdisk1
> hdisk1:
> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
> hd2 14 14 00..00..14..00..00 /usr
> fslv00 58 58 00..58..00..00..00 /app
> .....
>
> So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.
>
> Is there a way to 'fully mirror' this LV without backing up/removing filesystem
> and LV, then re-creating and restoring?
>
> Alex

lsvg -l rootvg tells you that you have 3 PVs (disks) associated to
fslv00. According to the lspv, you must have 10 LPs on (perhaps) hdisk2.

lslv -l fslv00
will tell you on which disks fslv00 is present.

syncvg -l fslv00
will synchronize the volume if the configuration is good, ie if there is
no missing physical disk.

Regards
Pierre-yves

[Database Administrator]

On Wed, 05 Nov 2008 12:27:43 +0100, Pierre-Yves Fontaniere
wrote:

>AlexB a ?crit :
>> Good day, everyone.
>>
>> Accidentally I found out that there is a potential problem on one of our AIX
>> boxes in rootvg. When displaying LVs in a VG, following warning message issued
>> for one of LVs:
>>
>> # lsvg -l rootvg
>> rootvg:
>> LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
>> hd5 boot 1 2 2 closed/syncd N/A
>> [...skipped...]
>> loglv00 jfs2log 1 1 1 open/syncd N/A
>> 0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
>> fslv00 jfs2 58 106 3 open/syncd /app
>>
>> I presume this happened when I was extending the '/app' filesystem some time ago
>> using 'smit chfs' menu. Not exactly sure how it happened, but the result is:
>>
>> # lspv -l hdisk0
>> hdisk0:
>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>> hd2 14 14 00..00..14..00..00 /usr
>> fslv00 48 48 00..48..00..00..00 /app
>> .....
>>
>> # lspv -l hdisk1
>> hdisk1:
>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>> hd2 14 14 00..00..14..00..00 /usr
>> fslv00 58 58 00..58..00..00..00 /app
>> .....
>>
>> So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.
>>
>> Is there a way to 'fully mirror' this LV without backing up/removing filesystem
>> and LV, then re-creating and restoring?
>>
>> Alex
>
>lsvg -l rootvg tells you that you have 3 PVs (disks) associated to
>fslv00. According to the lspv, you must have 10 LPs on (perhaps) hdisk2.
>
>lslv -l fslv00
>will tell you on which disks fslv00 is present.
>
>syncvg -l fslv00
>will synchronize the volume if the configuration is good, ie if there is
>no missing physical disk.
>
>Regards
>Pierre-yves

Thanks for pointing it out, Pierre-yves. I overlooked the number '3' in lspv
output. There seem to be an inconsistency in the odm then, I believe, as rootvg
has hdisk0 and hdisk1 only:

# lspv
hdisk0 00cefdde5b7db4e6 rootvg active
hdisk1 00cefdde356101e0 rootvg active
hdisk2 00cefddeae136cbe datavg active
hdisk3 00cefddeae187561 logvg active

lslv cannot display physical volumes for the fslv00, most probably due to
inconsistency:

# lslv -l fslv00
0516-022 : Illegal parameter or structure value.

I have checked two other disks hdisk2/hdisk3 (SAN LUNs, to be precise) and they
do not contain any parts of fslv00.

Now, it seems to be that my question should be rephrased as 'how do I repair
this inconsistency?'

Alex

[Database Administrator]

On Nov 5, 10:52 am, AlexB wrote:
> Good day, everyone.
>
> Accidentally I found out that there is a potential problem on one of our AIX
> boxes in rootvg. When displaying LVs in a VG, following warning message issued
> for one of LVs:
>
> # lsvg -l rootvg
> rootvg:
> LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
> hd5 boot 1 2 2 closed/syncd N/A
> [...skipped...]
> loglv00 jfs2log 1 1 1 open/syncd N/A
> 0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
> fslv00 jfs2 58 106 3 open/syncd /app
>
> I presume this happened when I was extending the '/app' filesystem some time ago
> using 'smit chfs' menu. Not exactly sure how it happened, but the result is:
>
> # lspv -l hdisk0
> hdisk0:
> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
> hd2 14 14 00..00..14..00..00 /usr
> fslv00 48 48 00..48..00..00..00 /app
> .....
>
> # lspv -l hdisk1
> hdisk1:
> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
> hd2 14 14 00..00..14..00..00 /usr
> fslv00 58 58 00..58..00..00..00 /app
> .....
>
> So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.
>
> Is there a way to 'fully mirror' this LV without backing up/removing filesystem
> and LV, then re-creating and restoring?
>
> Alex

Your fslv00 is using 3 ( THREE) disks! See you lsvg output (PVs =3)
check with
$ lslv fslv00 # With mirror level is used.
$ lslv -m fslv00 # How the mirror/LP distribution look like.

Further steps depend on your requirement for the fslv00
- mirror y/n
- allowed to span multiple disk y/n
- Seperate VG y/n

Normal no recreation is needed.

hth
Hajo



In case its a single mirror and you have no disk problems.
Reduce the mirror to one.
In case the rest is still on 2 disk use migratepv to move the stuff
onto a single disk
Check you LV setting for

[Database Administrator]

On Wed, 5 Nov 2008 04:31:58 -0800 (PST), Hajo Ehlers
wrote:

>On Nov 5, 10:52 am, AlexB wrote:
>> Good day, everyone.
>>
>> Accidentally I found out that there is a potential problem on one of our AIX
>> boxes in rootvg. When displaying LVs in a VG, following warning message issued
>> for one of LVs:
>>
>> # lsvg -l rootvg
>> rootvg:
>> LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
>> hd5 boot 1 2 2 closed/syncd N/A
>> [...skipped...]
>> loglv00 jfs2log 1 1 1 open/syncd N/A
>> 0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
>> fslv00 jfs2 58 106 3 open/syncd /app
>>
>> I presume this happened when I was extending the '/app' filesystem some time ago
>> using 'smit chfs' menu. Not exactly sure how it happened, but the result is:
>>
>> # lspv -l hdisk0
>> hdisk0:
>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>> hd2 14 14 00..00..14..00..00 /usr
>> fslv00 48 48 00..48..00..00..00 /app
>> .....
>>
>> # lspv -l hdisk1
>> hdisk1:
>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>> hd2 14 14 00..00..14..00..00 /usr
>> fslv00 58 58 00..58..00..00..00 /app
>> .....
>>
>> So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.
>>
>> Is there a way to 'fully mirror' this LV without backing up/removing filesystem
>> and LV, then re-creating and restoring?
>>
>> Alex
>
>Your fslv00 is using 3 ( THREE) disks! See you lsvg output (PVs =3)
>check with
>$ lslv fslv00 # With mirror level is used.
>$ lslv -m fslv00 # How the mirror/LP distribution look like.
>
>Further steps depend on your requirement for the fslv00
> - mirror y/n
> - allowed to span multiple disk y/n
> - Seperate VG y/n
>
>Normal no recreation is needed.
>
>hth
>Hajo
>
>
>
>In case its a single mirror and you have no disk problems.
>Reduce the mirror to one.
>In case the rest is still on 2 disk use migratepv to move the stuff
>onto a single disk
>Check you LV setting for

Thanks for explanation. It seems that there are actually 2 disks involved, but
somehow third one (PP3) 'creeped in', which does not exist:

# lslv fslv00
LOGICAL VOLUME: fslv00 VOLUME GROUP: rootvg
LV IDENTIFIER: 00cefdde00004c000000010335611a97.13 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 128 megabyte(s)
COPIES: 2 SCHED POLICY: parallel
LPs: 58 PPs: 116
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 32
MOUNT POINT: /app LABEL: /app
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO

# lslv -m fslv00|less
fslv00:/app
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0124 hdisk1 0123 hdisk0
0002 0125 hdisk1 0124 hdisk0
0003 0126 hdisk1 0125 hdisk0
0004 0127 hdisk1 0126 hdisk0
0005 0128 hdisk1 0127 hdisk0
0006 0129 hdisk1 0128 hdisk0
0007 0130 hdisk1 0129 hdisk0
0008 0131 hdisk1 0130 hdisk0
0009 0132 hdisk1 0131 hdisk0
0010 0133 hdisk1 0132 hdisk0
0011 0134 hdisk1 0133 hdisk0
0012 0135 hdisk1 0134 hdisk0
0013 0136 hdisk1 0135 hdisk0
0014 0137 hdisk1 0136 hdisk0
0015 0138 hdisk1 0137 hdisk0
0016 0139 hdisk1 0138 hdisk0
0017 0140 hdisk1 0139 hdisk0
0018 0141 hdisk1 0140 hdisk0
0019 0142 hdisk1 0141 hdisk0
0020 0143 hdisk1 0142 hdisk0
0021 0144 hdisk1 0143 hdisk0
0022 0145 hdisk1 0144 hdisk0
0023 0146 hdisk1 0145 hdisk0
0024 0147 hdisk1 0146 hdisk0
0025 0148 hdisk1 0147 hdisk0
0026 0149 hdisk1 0148 hdisk0
0027 0150 hdisk1 0149 hdisk0
0028 0151 hdisk1 0150 hdisk0
0029 0152 hdisk1 0151 hdisk0
0030 0153 hdisk1 0152 hdisk0
0031 0154 hdisk1 0153 hdisk0
0032 0155 hdisk1 0154 hdisk0
0033 0156 hdisk1 0155 hdisk0
0034 0157 hdisk1 0156 hdisk0
0035 0158 hdisk1 0157 hdisk0
0036 0159 hdisk1 0158 hdisk0
0037 0160 hdisk1 0159 hdisk0
0038 0161 hdisk1 0160 hdisk0
0039 0162 hdisk1 0161 hdisk0
0040 0163 hdisk1 0162 hdisk0
0041 0164 hdisk1 0163 hdisk0
0042 0165 hdisk1 0164 hdisk0
0043 0166 hdisk1 0165 hdisk0
0044 0167 hdisk1 0166 hdisk0
0045 0168 hdisk1 0167 hdisk0
0046 0169 hdisk1 0168 hdisk0
0047 0170 hdisk1 0169 hdisk0
0048 0171 hdisk1 0170 hdisk0
0049 0172 hdisk1
0050 0173 hdisk1
0051 0174 hdisk1
0052 0175 hdisk1
0053 0176 hdisk1
0054 0177 hdisk1
0055 0178 hdisk1
0056 0179 hdisk1
0057 0180 hdisk1
0058 0181 hdisk1

[Database Administrator]

On Wed, 05 Nov 2008 15:05:56 +0200, AlexB wrote:

>On Wed, 5 Nov 2008 04:31:58 -0800 (PST), Hajo Ehlers
>wrote:
>
>>On Nov 5, 10:52 am, AlexB wrote:
>>> Good day, everyone.
>>>
>>> Accidentally I found out that there is a potential problem on one of our AIX
>>> boxes in rootvg. When displaying LVs in a VG, following warning message issued
>>> for one of LVs:
>>>
>>> # lsvg -l rootvg
>>> rootvg:
>>> LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
>>> hd5 boot 1 2 2 closed/syncd N/A
>>> [...skipped...]
>>> loglv00 jfs2log 1 1 1 open/syncd N/A
>>> 0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
>>> fslv00 jfs2 58 106 3 open/syncd /app
>>>
>>> I presume this happened when I was extending the '/app' filesystem some time ago
>>> using 'smit chfs' menu. Not exactly sure how it happened, but the result is:
>>>
>>> # lspv -l hdisk0
>>> hdisk0:
>>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>>> hd2 14 14 00..00..14..00..00 /usr
>>> fslv00 48 48 00..48..00..00..00 /app
>>> .....
>>>
>>> # lspv -l hdisk1
>>> hdisk1:
>>> LV NAME LPs PPs DISTRIBUTION MOUNT POINT
>>> hd2 14 14 00..00..14..00..00 /usr
>>> fslv00 58 58 00..58..00..00..00 /app
>>> .....
>>>
>>> So, there are 48 LPs for this LV on hdisk0, but 58 LPs on hdisk1.
>>>
>>> Is there a way to 'fully mirror' this LV without backing up/removing filesystem
>>> and LV, then re-creating and restoring?
>>>
>>> Alex
>>
>>Your fslv00 is using 3 ( THREE) disks! See you lsvg output (PVs =3)
>>check with
>>$ lslv fslv00 # With mirror level is used.
>>$ lslv -m fslv00 # How the mirror/LP distribution look like.
>>
>>Further steps depend on your requirement for the fslv00
>> - mirror y/n
>> - allowed to span multiple disk y/n
>> - Seperate VG y/n
>>
>>Normal no recreation is needed.
>>
>>hth
>>Hajo
>>
>>
>>
>>In case its a single mirror and you have no disk problems.
>>Reduce the mirror to one.
>>In case the rest is still on 2 disk use migratepv to move the stuff
>>onto a single disk
>>Check you LV setting for
>
>Thanks for explanation. It seems that there are actually 2 disks involved, but
>somehow third one (PP3) 'creeped in', which does not exist:
>
># lslv fslv00
>LOGICAL VOLUME: fslv00 VOLUME GROUP: rootvg
>LV IDENTIFIER: 00cefdde00004c000000010335611a97.13 PERMISSION: read/write
>VG STATE: active/complete LV STATE: opened/syncd
>TYPE: jfs2 WRITE VERIFY: off
>MAX LPs: 512 PP SIZE: 128 megabyte(s)
>COPIES: 2 SCHED POLICY: parallel
>LPs: 58 PPs: 116
>STALE PPs: 0 BB POLICY: relocatable
>INTER-POLICY: minimum RELOCATABLE: yes
>INTRA-POLICY: middle UPPER BOUND: 32
>MOUNT POINT: /app LABEL: /app
>MIRROR WRITE CONSISTENCY: on/ACTIVE
>EACH LP COPY ON A SEPARATE PV ?: yes
>Serialize IO ?: NO
>
># lslv -m fslv00|less
>fslv00:/app
>LP PP1 PV1 PP2 PV2 PP3 PV3
>0001 0124 hdisk1 0123 hdisk0
>0002 0125 hdisk1 0124 hdisk0
>0003 0126 hdisk1 0125 hdisk0
>0004 0127 hdisk1 0126 hdisk0
>0005 0128 hdisk1 0127 hdisk0
>0006 0129 hdisk1 0128 hdisk0
>0007 0130 hdisk1 0129 hdisk0
>0008 0131 hdisk1 0130 hdisk0
>0009 0132 hdisk1 0131 hdisk0
>0010 0133 hdisk1 0132 hdisk0
>0011 0134 hdisk1 0133 hdisk0
>0012 0135 hdisk1 0134 hdisk0
>0013 0136 hdisk1 0135 hdisk0
>0014 0137 hdisk1 0136 hdisk0
>0015 0138 hdisk1 0137 hdisk0
>0016 0139 hdisk1 0138 hdisk0
>0017 0140 hdisk1 0139 hdisk0
>0018 0141 hdisk1 0140 hdisk0
>0019 0142 hdisk1 0141 hdisk0
>0020 0143 hdisk1 0142 hdisk0
>0021 0144 hdisk1 0143 hdisk0
>0022 0145 hdisk1 0144 hdisk0
>0023 0146 hdisk1 0145 hdisk0
>0024 0147 hdisk1 0146 hdisk0
>0025 0148 hdisk1 0147 hdisk0
>0026 0149 hdisk1 0148 hdisk0
>0027 0150 hdisk1 0149 hdisk0
>0028 0151 hdisk1 0150 hdisk0
>0029 0152 hdisk1 0151 hdisk0
>0030 0153 hdisk1 0152 hdisk0
>0031 0154 hdisk1 0153 hdisk0
>0032 0155 hdisk1 0154 hdisk0
>0033 0156 hdisk1 0155 hdisk0
>0034 0157 hdisk1 0156 hdisk0
>0035 0158 hdisk1 0157 hdisk0
>0036 0159 hdisk1 0158 hdisk0
>0037 0160 hdisk1 0159 hdisk0
>0038 0161 hdisk1 0160 hdisk0
>0039 0162 hdisk1 0161 hdisk0
>0040 0163 hdisk1 0162 hdisk0
>0041 0164 hdisk1 0163 hdisk0
>0042 0165 hdisk1 0164 hdisk0
>0043 0166 hdisk1 0165 hdisk0
>0044 0167 hdisk1 0166 hdisk0
>0045 0168 hdisk1 0167 hdisk0
>0046 0169 hdisk1 0168 hdisk0
>0047 0170 hdisk1 0169 hdisk0
>0048 0171 hdisk1 0170 hdisk0
>0049 0172 hdisk1
>0050 0173 hdisk1
>0051 0174 hdisk1
>0052 0175 hdisk1
>0053 0176 hdisk1
>0054 0177 hdisk1
>0055 0178 hdisk1
>0056 0179 hdisk1
>0057 0180 hdisk1
>0058 0181 hdisk1

Still no luck with repairing this problem. My idea is to remove hdisk0
completely from the mirror and then re-mirror rootvg from copy on hdisk1 to
hdisk0.

I thought I can unmirrorvg and then mirrorvg again to repair the situation.
Tried to unmirrorvg rootvg hdisk0 with no success. fslv00 is left on the hdisk0:

# unmirrorvg rootvg hdisk0
bash-2.05b# lspv -l hdisk1
hdisk1:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
hd2 14 14 00..00..14..00..00 /usr
fslv00 58 58 00..58..00..00..00 /app
hd9var 2 2 00..00..02..00..00 /var
hd8 1 1 00..00..01..00..00 N/A
hd4 1 1 00..00..01..00..00 /
hd5 1 1 01..00..00..00..00 N/A
lg_dumplv 8 8 00..08..00..00..00 N/A
hd6 4 4 00..04..00..00..00 N/A
paging00 60 60 00..00..60..00..00 N/A
loglv00 1 1 00..01..00..00..00 N/A
hd10opt 3 3 00..00..03..00..00 /opt
hd3 3 3 00..00..03..00..00 /tmp
hd1 8 8 00..00..08..00..00 /home
bash-2.05b# lspv -l hdisk0
hdisk0:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
fslv00 48 48 00..48..00..00..00 /app

# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 1 1 closed/syncd N/A
hd6 paging 4 4 1 open/syncd N/A
hd8 jfslog 1 1 1 open/syncd N/A
hd4 jfs 1 1 1 open/syncd /
hd2 jfs 14 14 1 open/syncd /usr
hd9var jfs 2 2 1 open/syncd /var
hd3 jfs 3 3 1 open/syncd /tmp
hd1 jfs 8 8 1 open/syncd /home
hd10opt jfs 3 3 1 open/syncd /opt
lg_dumplv sysdump 8 8 1 open/syncd N/A
paging00 paging 60 60 1 open/syncd N/A
loglv00 jfs2log 1 1 1 open/syncd N/A
0516-1147 : Warning - logical volume fslv00 may be partially mirrored.
fslv00 jfs2 58 106 3 open/syncd /app

still 3 copies of fslv00 somehow, but 'lslv' shows only 2:

# lslv -L fslv00
LOGICAL VOLUME: fslv00 VOLUME GROUP: rootvg
LV IDENTIFIER: 00cefdde00004c000000010335611a97.13 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 128 megabyte(s)
COPIES: 2 SCHED POLICY: parallel
LPs: 58 PPs: 116
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 32
MOUNT POINT: /app LABEL: /app
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO

Tried migratepv afterwards, to 'clean' hdisk0 completely and then re-create the
mirror. Failure again..

# migratepv hdisk0 hdisk1
0516-1244 migratepv: Destination physical volume hdisk1 contains
partitions of the logical volume fslv00.
0516-812 migratepv: Warning, migratepv did not completely succeed;
all physical partitions have not been moved off the PV.

To my understanding hdisk0 now contains only a partial mirror copy of fslv00 (as
it has 48 LPs against 58 LPs on hdisk1). I must be doing something reallysilly.
Anyone to advise?

Alex

[Database Administrator]

The important output is this one:
....
> COPIES: 2
....



>
> # lslv -m fslv00|less

This command will show the distribution for your lv but NOT the copy
count.
The output is just fixed for 3 copies since you can triple mirror.

> fslv00:/app
> LP PP1 PV1 PP2 PV2 PP3 PV3
> 0001 0124 hdisk1 0123 hdisk0
....
> 0046 0169 hdisk1 0168 hdisk0
> 0047 0170 hdisk1 0169 hdisk0
> 0048 0171 hdisk1 0170 hdisk0
> 0057 0180 hdisk1
> 0058 0181 hdisk1

[Database Administrator]

unmirrorvg is not the tool of choice. Afaik unmirrorvg will unmirror
system lv within rootvg.

Anyway use rmlvcopy to reduce the copy count for your fslv00
Example:
$ rmlvcopy fslv00 1 hdisk0

If that will not work:
Use cplv to copy fslv00 to a new lv.
Steps can be found at:
http://www-01.ibm.com/support/docvie...d=isg3T1000167

Please be aware that its look like that fslv00 is using loglv00
So in case the new lv for your /app shall be mounted you should format
the JFS2 log with logform.
( I assume only fslv00 is currently using this log )
The above technote give details about that.

hth
Hajo

[Database Administrator]

On Wed, 5 Nov 2008 10:08:02 -0800 (PST), Hajo Ehlers
wrote:

>unmirrorvg is not the tool of choice. Afaik unmirrorvg will unmirror
>system lv within rootvg.
>
>Anyway use rmlvcopy to reduce the copy count for your fslv00
>Example:
>$ rmlvcopy fslv00 1 hdisk0
>
>If that will not work:
>Use cplv to copy fslv00 to a new lv.
>Steps can be found at:
>http://www-01.ibm.com/support/docvie...d=isg3T1000167
>
>Please be aware that its look like that fslv00 is using loglv00
>So in case the new lv for your /app shall be mounted you should format
>the JFS2 log with logform.
>( I assume only fslv00 is currently using this log )
>The above technote give details about that.
>
>hth
>Hajo

You are right, rmlvcopy did not work!

# rmlvcopy fslv00 1 hdisk0
0516-022 lquerypv: Illegal parameter or structure value.
0516-304 getlvodm: Unable to find device id 0000000000000000 in the Device
Configuration Database.
0516-848 rmlvcopy: Failure on physical volume 0000000000000000, it may be
missing
or removed.


Must be something wrong in ODM!

I will follow the instruction to copy LV to another VG, or, maybe, it will be
easier just to 'tar' everything to an NFS directory, remove fs and re-create it.
Thanks a lot for your help and link to instructions, it is clear right now!

Alex

[Database Administrator]

On Nov 6, 2:23*am, AlexB wrote:
> On Wed, 5 Nov 2008 10:08:02 -0800 (PST), Hajo Ehlers
> wrote:
>
>
>
>
>
> >unmirrorvg is not the tool of choice. Afaik unmirrorvg will unmirror
> >system lv within rootvg.
>
> >Anyway use rmlvcopy to reduce the copy count for your fslv00
> >Example:
> >$ rmlvcopy fslv00 1 hdisk0
>
> >If that will not work:
> >Use cplv to copy fslv00 to a new lv.
> >Steps can be found at:
> >http://www-01.ibm.com/support/docvie...d=isg3T1000167
>
> >Please be aware that its look like that fslv00 is using loglv00
> >So in case the new lv for your /app shall be mounted you should format
> >the JFS2 log with logform.
> >( I assume only fslv00 is currently using this log )
> >The above technote give details about that.
>
> >hth
> >Hajo
>
> You are right, rmlvcopy did not work!
>
> # rmlvcopy fslv00 1 hdisk0
> 0516-022 lquerypv: Illegal parameter or structure value.
> 0516-304 getlvodm: Unable to find device id 0000000000000000 in the Device
> * * * * Configuration Database.
> 0516-848 rmlvcopy: Failure on physical volume 0000000000000000, it may be
> missing
> * * * * or removed.
>
> Must be something wrong in ODM!
>
> I will follow the instruction to copy LV to another VG, or, maybe, it will be
> easier just to 'tar' everything to an NFS directory, remove fs and re-create it.
> Thanks a lot for your help and link to instructions, it is clear right now!
>
> Alex

you could try this... it is not supported, but it worked for me in the
same situation previously.

1. Make a backup before you do anything

2. Create the map file to specify the PPs you want to remove:
# lquerylv -L `getlvodm -l fslv00` -r > /tmp/mapfile

3. vi /tmp/mapfile and remove all the good entries.
ie, leave only the entries with the pvid of hdisk0 in the file.

4. Deallocate the PPs using lreducelv

# lreducelv -l `getlvodm -l fslv00` -s /
tmp/mapfile

After we are done we should then see lslv -m fslv00 have only one copy
and
lsvg -l rootvg should have the same number for lps and pps.