I have a three-node cluster (when no satellite or test system has joined
it) and physical disks (blue SBB in BA356) on each node (no dual-ported
disks; each disk has a direct connection to only one node). All disks
are HBVS; system disks have both members on one node while others have
both (in one case three) members on different nodes. I've been running
such a setup (though with different machines, even different
architectures, different disks, different expansion boxes) for decades.

When something fails, I just replace it with something of similar build.
(The main reason for moving to SBB disks was to be able to replace a
disk (the most common failure) without having to dismount the members it
hosts, shut down the system, remove it from the shelf, open it, replace
the disk, close it, put it back on the shelf, boot it, remount the
members it hosts.)

For a while now I've noticed disks going in and out of mount
verification. It is clear which node is involved. So, my plan is to
replace hardware (and maybe try to find the problem when the hardware is
out of the cluster) and hope that it goes away. Since all disks with
members on this system, but no others, are involved, it is clear that
the problem is only on one node. It is unlikely to be a problem with
the physical SCSI disks.

Theoretically it could be the SCSI cable, but my guess is that it is
either the expansion box or the SCSI card. (I have had one expansion
box fail, but it failed completely.) Which is more likely?

Has anyone seen anything like this before? The mount-verification
problem occurs regularly every few minutes, but always completes
automatically after a few seconds or half a minute or so (depending on
the shadow set).

It would be easiest to replace the BA356: dismount the members, power
down the box, remove the members, stick them in another box, swap the
cables, power up the other box, remount the members (and be very
thankful for MINICOPY). Of course, if it is exceedingly unlikely that
the box is the problem, as opposed to the SCSI card (or something else
which I haven't thought of), then that would be a waste of time.

Thoughts?

In article <sbc86h$656$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> I have a three-node cluster (when no satellite or test system has joined
> it) and physical disks (blue SBB in BA356) on each node (no dual-ported
> disks; each disk has a direct connection to only one node).

> When something fails, I just replace it with something of similar build.
> (The main reason for moving to SBB disks was to be able to replace a
> disk (the most common failure) without having to dismount the members it
> hosts, shut down the system, remove it from the shelf, open it, replace
> the disk, close it, put it back on the shelf, boot it, remount the
> members it hosts.)
>
> For a while now I've noticed disks going in and out of mount
> verification. It is clear which node is involved. So, my plan is to
> replace hardware (and maybe try to find the problem when the hardware is
> out of the cluster) and hope that it goes away.

> Theoretically it could be the SCSI cable, but my guess is that it is
> either the expansion box or the SCSI card. (I have had one expansion
> box fail, but it failed completely.) Which is more likely?

I try to keep enough hardware on hand to last me until I die. However,
since a BA356 failed a couple of years ago, and another one might be
failing now, the fact that I have only two spares is a bit unsettling.
Does anyone in Europe have any BLUE BA356 boxes they would like to give
to a good home? (I might be willing to offer some older hardware in
exchange, in particular VAX-related stuff.) Shipping is probably too
expensive, but I'll probably be passing through sometime in the next
several months.

The boxes have to be Top-Gun Blue, since I also have the blue disks.
(Since disks almost always fail at some point, such disks would also be
interesting for me; one can't have too many spare disks.)

In article <sbc8uu$hn9$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> In article <sbc86h$656$1@gioia.aioe.org>,
> helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
> writes:
>
> > I have a three-node cluster (when no satellite or test system has joined
> > it) and physical disks (blue SBB in BA356) on each node (no dual-ported
> > disks; each disk has a direct connection to only one node).
>
> > When something fails, I just replace it with something of similar build.
> > (The main reason for moving to SBB disks was to be able to replace a
> > disk (the most common failure) without having to dismount the members it
> > hosts, shut down the system, remove it from the shelf, open it, replace
> > the disk, close it, put it back on the shelf, boot it, remount the
> > members it hosts.)
> >
> > For a while now I've noticed disks going in and out of mount
> > verification. It is clear which node is involved. So, my plan is to
> > replace hardware (and maybe try to find the problem when the hardware is
> > out of the cluster) and hope that it goes away.
>
> > Theoretically it could be the SCSI cable, but my guess is that it is
> > either the expansion box or the SCSI card. (I have had one expansion
> > box fail, but it failed completely.) Which is more likely?

OK, spent some time staring at hardware in the cellar. :-| It seems
that before the mount verification sets in, the two LEDs to the left of
the plug in the power supply go out, then come back on, then all the
disks light up briefly. So probably a problem with the box or the power
supply.

I can try replacing the power supply first, if that doesn't help then
the SCSI interface at the top, then if that doesn't help the entire box.

Any other ideas?

On Monday, June 28, 2021 at 6:57:43 AM UTC-4, Phillip Helbig (undress to reply) wrote:
> In article <sbc8uu$hn9$1...@gioia.aioe.org>,
> hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))
> writes:
>
> > In article <sbc86h$656$1...@gioia.aioe.org>,
> > hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))
> > writes:
> >
> > > I have a three-node cluster (when no satellite or test system has joined
> > > it) and physical disks (blue SBB in BA356) on each node (no dual-ported
> > > disks; each disk has a direct connection to only one node).
> >
> > > When something fails, I just replace it with something of similar build.
> > > (The main reason for moving to SBB disks was to be able to replace a
> > > disk (the most common failure) without having to dismount the members it
> > > hosts, shut down the system, remove it from the shelf, open it, replace
> > > the disk, close it, put it back on the shelf, boot it, remount the
> > > members it hosts.)
> > >
> > > For a while now I've noticed disks going in and out of mount
> > > verification. It is clear which node is involved. So, my plan is to
> > > replace hardware (and maybe try to find the problem when the hardware is
> > > out of the cluster) and hope that it goes away.
> >
> > > Theoretically it could be the SCSI cable, but my guess is that it is
> > > either the expansion box or the SCSI card. (I have had one expansion
> > > box fail, but it failed completely.) Which is more likely?
> OK, spent some time staring at hardware in the cellar. :-| It seems
> that before the mount verification sets in, the two LEDs to the left of
> the plug in the power supply go out, then come back on, then all the
> disks light up briefly. So probably a problem with the box or the power
> supply.
>
> I can try replacing the power supply first, if that doesn't help then
> the SCSI interface at the top, then if that doesn't help the entire box.
>
> Any other ideas?
If all of the drives on that controller go through verification at the same time, then yes the common points are the controller itself, the controller in the SBB box and the power supply. Given that the lights change, I would look to the supply first. In the last 15 years of supporting a site with 12 of these, I have seen 1 power supply fail and 2 Alpha disk controllers fail (not including individual disks). At another client site, I did see one of the BA box controllers fail (BA35X-DA).

I do have spares of the BA35X-FA (dual scsi version of the -DA). I am in the US so I don't know the cost of shipping,but i have more than 10 of these if it helps you out.

Dan

In article <9cebac77-8c98-41f1-aa9a-94bd2e747bf8n@googlegroups.com>,
abrsvc <dansabrservices@yahoo.com> writes:

> If all of the drives on that controller go through verification at the same
> time,

Pretty much.

> then yes the common points are the controller itself, the controller
> in the SBB box and the power supply. Given that the lights change, I would
> look to the supply first.

Will do.

> I do have spares of the BA35X-FA (dual scsi version of the -DA). I am in
> the US so I don't know the cost of shipping, but i have more than 10 of these
> if it helps you out.

Thanks, but a) shipping is probably not worth it and b) I do have enough
spares for the box controllers (the module at the top which the cable
connects to). I'll swap the power supply and see what happens.

In article <sbcame$1d62$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> > If all of the drives on that controller go through verification at the same
> > time,
>
> Pretty much.
>
> > then yes the common points are the controller itself, the controller
> > in the SBB box and the power supply. Given that the lights change, I would
> > look to the supply first.
>
> Will do.
>
> > I do have spares of the BA35X-FA (dual scsi version of the -DA). I am in
> > the US so I don't know the cost of shipping, but i have more than 10 of these
> > if it helps you out.
>
> Thanks, but a) shipping is probably not worth it and b) I do have enough
> spares for the box controllers (the module at the top which the cable
> connects to). I'll swap the power supply and see what happens.

Swapping the power supply seems to have fixed the problem. Took less
than a minute.

In article <sbcc4i$2ir$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> Swapping the power supply seems to have fixed the problem. Took less
> than a minute.

After a couple of hours, no more mount verification. I would have
thought that a power supply would fail completely and suddenly, rather
than going in and out for weeks. :-|

Yes, I know that it is old hardware, but now rising to the top of the
pile is the task to make concrete plans to move to x86 as soon as
hardware, software, licenses, etc. are available at a price I can afford
and which will be functionally at least equivalent to what I have now
with non-VSI Alpha (Compaq and HP sofware, DEC and Compaq hardware).

On Monday, June 28, 2021 at 9:33:42 AM UTC-4, Phillip Helbig (undress to reply) wrote:
> In article <sbcc4i$2ir$1...@gioia.aioe.org>,
> hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))
> writes:
> > Swapping the power supply seems to have fixed the problem. Took less
> > than a minute.
> After a couple of hours, no more mount verification. I would have
> thought that a power supply would fail completely and suddenly, rather
> than going in and out for weeks. :-|
>
> Yes, I know that it is old hardware, but now rising to the top of the
> pile is the task to make concrete plans to move to x86 as soon as
> hardware, software, licenses, etc. are available at a price I can afford
> and which will be functionally at least equivalent to what I have now
> with non-VSI Alpha (Compaq and HP sofware, DEC and Compaq hardware).

I would guess that the filtering on the outputs are starting to go bad. This would introduce some variance in the voltages that may trigger the protection circuits.

See how much it would cost to send it to me in the US (I'll cover the cost) so I can check it out.
Contact me directly for an address at the Email below.

Dan

Dansabrservices@yahoo.com

In article <80ff10c9-f654-48f7-98b1-7005b6988ee2n@googlegroups.com>,
abrsvc <dansabrservices@yahoo.com> writes:

> I would guess that the filtering on the outputs are starting to go
> bad. This would introduce some variance in the voltages that may
> trigger the protection circuits.

Could be.

> See how much it would cost to send it to me in the US (I'll cover the
> cost) so I can check it out.

Certainly not worth the trouble, as spares are not that difficult to
find.