• best guess for mount-verification problem

    From Hans Bachner@21:1/5 to All on Mon Jun 28 16:04:59 2021
    Phillip,

    Phillip Helbig (undress to reply) schrieb am 28.06.2021 um 12:57:
    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?

    If you don't have a disk in slot 6 you could plug in a second power
    supply and watch whether the problem (the mount verifications, not the
    flashing LEDs) disappears.

    Anything in VMS's error log? $ DIAG is your friend in this case.

    Hope this helps,
    Hans.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to hans@bachner.priv.at on Mon Jun 28 19:21:39 2021
    In article <iju38bFspqiU1@mid.individual.net>, Hans Bachner <hans@bachner.priv.at> writes:

    If you don't have a disk in slot 6 you could plug in a second power
    supply and watch whether the problem (the mount verifications, not the flashing LEDs) disappears.

    All slots are full. :-( I like the idea of two power supplies, but not
    the idea of not using one of the addresses. Even in the case of
    complete failure, each shadow set would have at least one member on at
    least one node, so processing could continue. For my hobbyist purposes,
    it is enough (and saves on power) to have just one power supply and swap
    if necessary.

    Anything in VMS's error log? $ DIAG is your friend in this case.

    Will have to take a look. The problem has been solved, but I can learn something about DIAG and so on.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)