Alternate disk problems

[Philip Dunn_1]

Hi,
Wonder if somebody could suggest any ideas...

After a server crash, a volume group is complaining about missing disks on an XP array. On investigation the disks that it is complaining about are the alternative paths to the disk.

The problem is the server can see these disks, we have ioscan'd and insf -e'd but the volume group is still complaining, despite being able to diskinfo the disks.

We have tried vgreducing the alternative path, but it complains. I am a bit weary about using the -f flag as you cannot specify each alternate link, and I have read it can loose data.

Does anybody have some ideas to try and make the volume group believe it once again has these links?

Many Thanks

Phil

[Frank de Vries]

we run a n-class cluster via two brocades
to an XP256 diskarray ,and we too have the
messages about the alternate path.

Sofar from our experience they cause no
harm, but you should not try to tamper
with them either.

Despite the messages we run continuous copy
or business copy without any problems.

It may be a good thing to document them,
you can always work back from the hardwarePath to the lun on the XP.

[Fabio Ettore]

Hi Philip,

I faced a similar problem a few months ago. Disks were in status 'unavailable' (by vgdisplay -v ) and I got 'couldn't query....'.
I just launched

vgchange -a y

to solve the problem.
In that way VG's should recognize again the missing disks. Also it is not dangerous since just it tries to re-activate ex-missing disks.

HTH.

Best regards,
Fabio

[AndyMueller]

I find that sometimes things get a bit goofy in the /etc/lvmtab file. How about doint a strings /etc/lvmtab? Are your alternate path disks listed? Are they the correct ones? If not (or even if they are), mv /etc/lvmtab /etc/lvmtab.old, then issue a vgscan -a (this will re-create this file).
See if the disks look better now. What happens if you were to try to vgextend the VG for one of your alternate disks? What error do you get? Can you post it?

Andy