Hi.
We have 5 non-RAID disks in one SSA enclosure mirrored to 5 disks in another
enclosure. Yesterday I relaced a faulty 36GB disk, pdisk7/hdisk9 containing
logical volumes xraplv and tarclv. The steps (for those who are interested
because it's probably quite a useful procedure) were as follows:

q Remove hdisk9 from the mirror
rmlvcopy xraplv 1 hdisk9
rmlvcopy tarclv 1 hdisk9
reducevg redunvg hdisk9

q Delete hdisk9 and the corresponding pdisk7
rmdev -dl hdisk9
rmdev -dl pdisk7

q Remove the faulty disk

q Insert the replacement disk

q Run cfgmgr to have the new disk sensed as pdisk7

q Certify the new disk (may take 1 hour)
diag # task selection, SSA service aids, certify disks, pdisk7

q Recreate the mirror
extendvg redunvg hdisk9
mklvcopy xraplv 2 hdisk9
mklvcopy tarclv 2 hdisk9

q Run syncvg to synchronise the mirrors (may take 1.25 hours)
syncvg -v redunvg

Now I come to my question (for those who are still reading).

My mirror is as shown below, with the upper disks (or actually their logical
volumes) mirrored to the lower ones:



pdisk0 pdisk1 pdisk2 pdisk3 pdisk4

pdisk5 pdisk6 pdisk7 pdisk8 pdisk9



I found that the logical volumes on pdisk1 are mirrored to pdisk7, not
pdisk6 as expected, and correspondingly pdisk2 is mirrored to pdisk6. The
pdisk order matches the physical slots that the disks are in (which is what
I want), so swapping the disks isn't the right solution. What I have to do
is swap the logical volumes between pdisk6 and pdisk7. This wouldn't be a
problem except that pdisk6, pdisk8, and pdisk9 are each 36GB and comprise
one large logical volume. I can split the mirror for pdisks 6, 7, 8, and 9,
reform it with the right file systems on the right disks, but the syncvg
will take 5 hours and the processor will be almost permanently in wait state
during that time. We are a 24 hour air traffic operation, wishing to
minimise risk of application down-time. Is there a way of swapping the file
systems on pdisk6 and 7 without having to re-sync the whole of pdisks 8 and
9 as well?

Probably asking too much...

Thanks anyway,

Jeffrey.

"Jeffrey Ross" <jeffrey.rossATairways.co.nz@no.spam> schrieb im Newsbeitrag
news:419d2482$1@news.iconz.co.nz...
[some snipped]
>
> Now I come to my question (for those who are still reading).
|-)
>
> My mirror is as shown below, with the upper disks (or actually their
logical
> volumes) mirrored to the lower ones:
>
> pdisk0 pdisk1 pdisk2 pdisk3 pdisk4
>
> pdisk5 pdisk6 pdisk7 pdisk8 pdisk9
>
> I found that the logical volumes on pdisk1 are mirrored to pdisk7, not
> pdisk6 as expected, and correspondingly pdisk2 is mirrored to pdisk6. The
> pdisk order matches the physical slots that the disks are in (which is
what
> I want), so swapping the disks isn't the right solution. What I have to
do
> is swap the logical volumes between pdisk6 and pdisk7. This wouldn't be a
> problem except that pdisk6, pdisk8, and pdisk9 are each 36GB and comprise
> one large logical volume. I can split the mirror for pdisks 6, 7, 8, and
9,
> reform it with the right file systems on the right disks, but the syncvg
> will take 5 hours and the processor will be almost permanently in wait
state
> during that time. We are a 24 hour air traffic operation, wishing to
> minimise risk of application down-time. Is there a way of swapping the
file
> systems on pdisk6 and 7 without having to re-sync the whole of pdisks 8
and
> 9 as well?
>
> Probably asking too much...
>
> Thanks anyway,
>
> Jeffrey.
>
Hallo Jeffrey,

Syncing is done on volumegroup level but you can tell syncvg to synchronise
up to 32 PP in parallel. Defaults to 1 and that is why it takes soooooooooo
long. You might need some testing to find out how many PP can by sync'd in
parallel on your fs to find an optimal value. Start with say 8 and you will
be surprised positively how much faster syncing will take place. Secondly
you could use syncvg in the background by simply issuing a varyonvg
<yourvg>. Either way should alleviate moving the lvs around.

HTH,
Andreas

"Andreas Schulze" <b79xan@gmx.de> wrote in message
news:cnkteo$mfo$1@tgx093.str.allianz.de...
> "Jeffrey Ross" <jeffrey.rossATairways.co.nz@no.spam> schrieb im
Newsbeitrag
> news:419d2482$1@news.iconz.co.nz...
> [some snipped]
> >
> > Now I come to my question (for those who are still reading).
> |-)
> >
> > My mirror is as shown below, with the upper disks (or actually their
> logical
> > volumes) mirrored to the lower ones:
> >
> > pdisk0 pdisk1 pdisk2 pdisk3 pdisk4
> >
> > pdisk5 pdisk6 pdisk7 pdisk8 pdisk9
> >
> > I found that the logical volumes on pdisk1 are mirrored to pdisk7, not
> > pdisk6 as expected, and correspondingly pdisk2 is mirrored to pdisk6.
The
> > pdisk order matches the physical slots that the disks are in (which is
> what
> > I want), so swapping the disks isn't the right solution. What I have to
> do
> > is swap the logical volumes between pdisk6 and pdisk7. This wouldn't be
a
> > problem except that pdisk6, pdisk8, and pdisk9 are each 36GB and
comprise
> > one large logical volume. I can split the mirror for pdisks 6, 7, 8,
and
> 9,
> > reform it with the right file systems on the right disks, but the syncvg
> > will take 5 hours and the processor will be almost permanently in wait
> state
> > during that time. We are a 24 hour air traffic operation, wishing to
> > minimise risk of application down-time. Is there a way of swapping the
> file
> > systems on pdisk6 and 7 without having to re-sync the whole of pdisks 8
> and
> > 9 as well?
> >
> > Probably asking too much...
> >
> > Thanks anyway,
> >
> > Jeffrey.
> >
> Hallo Jeffrey,
>
> Syncing is done on volumegroup level but you can tell syncvg to
synchronise
> up to 32 PP in parallel. Defaults to 1 and that is why it takes
soooooooooo
> long. You might need some testing to find out how many PP can by sync'd in
> parallel on your fs to find an optimal value. Start with say 8 and you
will
> be surprised positively how much faster syncing will take place. Secondly
> you could use syncvg in the background by simply issuing a varyonvg
> <yourvg>. Either way should alleviate moving the lvs around.
>
> HTH,
> Andreas
>
Thanks, Andreas.
That's an option that I didn't spot. Will do some testing using it.
Much appreciated,
Jeffrey.

"Jeffrey Ross" <jeffrey.rossATairways.co.nz@no.spam> wrote in message news:<419d2482$1@news.iconz.co.nz>...
> Hi.
> We have 5 non-RAID disks in one SSA enclosure mirrored to 5 disks in another
> enclosure. Yesterday I relaced a faulty 36GB disk, pdisk7/hdisk9 containing
> logical volumes xraplv and tarclv. The steps (for those who are interested
> because it's probably quite a useful procedure) were as follows:
>
> q Remove hdisk9 from the mirror

AIX from (I believe) 5.1 has a very handy tool called replacepv. It
will work as long as you have a slot free in your SSA cabinet. Simply
add the new disk, run cfgmgr to add it, find out which hdisk it has
become and execute:

replacepv hdisk9 hdisk20

You will end up with hdisk20 taking the place of hdisk9, which you can
then rmdev and remove. One thing: you can replacepv to a disk the same
size or larger, but not smaller, even if the data on the old disk will
normally fit. Also, you end up with an hdisk20 where an hdisk9 used to
be. AIX doesn't care, but it looks strange. It even works if the old
disk is dead and (maybe) even removed from the system. Mirror data
will be used.

No more annoying rebuilds of the mirrors...

Cheers,
Menno