strange disk states - VMS

This is a discussion on strange disk states - VMS ; I'll post another message about the ultimate cause of the problem. Right now, I'm wondering how one member of DSA510: can be a copy target and the other member in the "merging" status. Shouldn't either no or both members be ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: strange disk states

  1. strange disk states

    I'll post another message about the ultimate cause of the problem.
    Right now, I'm wondering how one member of DSA510: can be a copy target
    and the other member in the "merging" status. Shouldn't either no or
    both members be in the "merging" status? Or will first a copy happen
    then a merge? (I'll have to wait about 10 hours to find out. We plan
    to move next spring; maybe that will be a chance for me to get some
    faster hardware.)

    The disk appears to work fine from all nodes.

    GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes. DANEEL has been acting
    strange lately, but this time ELIJAH was too. I tried a shutdown on
    ELIJAH, which hung. Couldn't get a prompt on the DANEEL console, so did
    a reset, as on ELIJAH. Both hung. Only after a power cycle did they
    come back up. I didn't reboot GLADIA.

    The strange status of DSA510: is the same on all nodes. Now, a few
    minutes later, $22$DKA500: is showing 1% copied. The only difference is
    that $22$DKA400: is in MntVerifyTimeout only on DANEEL; a MOUNT fixed
    that. Otherwise all the disks look as expected.

    Device Device Error Volume Free Trans Mnt
    Name Status Count Label Blocks Count Cnt
    $22$DKA200: (DANEEL) ShadowCopying 0 (copy trgt DSA520: 0% copied)
    $22$DKA300: (DANEEL) ShadowMergeMbr 0 (merging DSA122: 66% merged)
    $22$DKA400: (DANEEL) MntVerifyTimeout 0 OVMSDOC071 61179 1 3
    wrtlck
    $22$DKA500: (DANEEL) ShadowCopying 0 (copy trgt DSA510: 0% copied)
    $22$DKA700: (DANEEL) ShadowMergeMbr 0 (merging DSA122: 66% merged)
    $33$DKA200: (GLADIA) Online 0
    $33$DKA300: (GLADIA) ShadowSetMember 36 (member of DSA520
    $33$DKA400: (GLADIA) Online wrtlck 0
    $33$DKB100: (GLADIA) ShadowMergeMbr 0 (merging DSA133: 90% merged)
    $33$DKB600: (GLADIA) ShadowMergeMbr 0 (merging DSA133: 90% merged)
    $44$DKA100: (ELIJAH) ShadowMergeMbr 0 (merging DSA144: 76% merged)
    $44$DKA200: (ELIJAH) Mounted 0 SCRATCH_4 168837 2 3
    $44$DKA300: (ELIJAH) Mounted 0 DATA 1907185 1 3
    $44$DKA400: (ELIJAH) ShadowMergeMbr 0 (merging DSA510: 0% merged)
    $44$DKA600: (ELIJAH) ShadowMergeMbr 0 (merging DSA144: 76% merged)
    $131$DKA300: (NADILA) HostUnavailable 0
    $131$DKA500: (NADILA) HostUnavailable 0

    For completeness:

    Device Device Error Volume Free Trans Mnt
    Name Status Count Label Blocks Count Cnt
    DSA122: Mounted 0 OVMSVAXSYS_2 2139480 347 3
    DSA133: Mounted 0 ALPHASYS_3 1934613 1 3
    DSA144: Mounted 0 OVMSVAXSYS_4 2060704 1 3
    DSA510: Mounted 0 USER 5533721 219 3
    DSA520: Mounted 0 SOFT 514653 9 3


  2. Re: strange disk states

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:

    >I'll post another message about the ultimate cause of the problem.
    >Right now, I'm wondering how one member of DSA510: can be a copy target
    >and the other member in the "merging" status. Shouldn't either no or
    >both members be in the "merging" status?


    That state wasn't possible back when I was messing with shadowing. You
    needed 2 or more full members to be in a merge state. It may be that
    they've updated shadowing in such a way that a copy target can be a source
    if reading from below the copy fence, otherwise no. If that is the case,
    the normal need for a merge would apply, and I don't know how they'd
    handle that.

  3. Re: strange disk states

    In article , helbig@astro.multiCLOTHESvax.de
    says...
    > I'll post another message about the ultimate cause of the problem.
    > Right now, I'm wondering how one member of DSA510: can be a copy target
    > and the other member in the "merging" status. Shouldn't either no or
    > both members be in the "merging" status? Or will first a copy happen
    > then a merge? (I'll have to wait about 10 hours to find out. We plan
    > to move next spring; maybe that will be a chance for me to get some
    > faster hardware.)
    >
    > The disk appears to work fine from all nodes.
    >
    > GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes. DANEEL has been acting
    > strange lately, but this time ELIJAH was too. I tried a shutdown on
    > ELIJAH, which hung. Couldn't get a prompt on the DANEEL console, so did
    > a reset, as on ELIJAH. Both hung. Only after a power cycle did they
    > come back up. I didn't reboot GLADIA.
    >
    > The strange status of DSA510: is the same on all nodes. Now, a few
    > minutes later, $22$DKA500: is showing 1% copied. The only difference is
    > that $22$DKA400: is in MntVerifyTimeout only on DANEEL; a MOUNT fixed
    > that. Otherwise all the disks look as expected.
    >
    > Device Device Error Volume Free Trans Mnt
    > Name Status Count Label Blocks Count Cnt
    > $22$DKA200: (DANEEL) ShadowCopying 0 (copy trgt DSA520: 0% copied)
    > $22$DKA300: (DANEEL) ShadowMergeMbr 0 (merging DSA122: 66% merged)
    > $22$DKA400: (DANEEL) MntVerifyTimeout 0 OVMSDOC071 61179 1 3
    > wrtlck
    > $22$DKA500: (DANEEL) ShadowCopying 0 (copy trgt DSA510: 0% copied)
    > $22$DKA700: (DANEEL) ShadowMergeMbr 0 (merging DSA122: 66% merged)
    > $33$DKA200: (GLADIA) Online 0
    > $33$DKA300: (GLADIA) ShadowSetMember 36 (member of DSA520
    > $33$DKA400: (GLADIA) Online wrtlck 0
    > $33$DKB100: (GLADIA) ShadowMergeMbr 0 (merging DSA133: 90% merged)
    > $33$DKB600: (GLADIA) ShadowMergeMbr 0 (merging DSA133: 90% merged)
    > $44$DKA100: (ELIJAH) ShadowMergeMbr 0 (merging DSA144: 76% merged)
    > $44$DKA200: (ELIJAH) Mounted 0 SCRATCH_4 168837 2 3
    > $44$DKA300: (ELIJAH) Mounted 0 DATA 1907185 1 3
    > $44$DKA400: (ELIJAH) ShadowMergeMbr 0 (merging DSA510: 0% merged)
    > $44$DKA600: (ELIJAH) ShadowMergeMbr 0 (merging DSA144: 76% merged)
    > $131$DKA300: (NADILA) HostUnavailable 0
    > $131$DKA500: (NADILA) HostUnavailable 0
    >
    > For completeness:
    >
    > Device Device Error Volume Free Trans Mnt
    > Name Status Count Label Blocks Count Cnt
    > DSA122: Mounted 0 OVMSVAXSYS_2 2139480 347 3
    > DSA133: Mounted 0 ALPHASYS_3 1934613 1 3
    > DSA144: Mounted 0 OVMSVAXSYS_4 2060704 1 3
    > DSA510: Mounted 0 USER 5533721 219 3
    > DSA520: Mounted 0 SOFT 514653 9 3
    >
    >


    Looks pretty strange.

    (If you did a "show device" for a single shadow set (e.g. $ show device
    dsa510:, or a single member disk (e.g. $ show device $44$DKA400, it
    would list the shadow set (DSA) disk followed by all the members, which
    would be a little easier to read. I missread the status of DSA510: at
    first due to the info being scattered all over the place.)

    Anyway, I expect if a two member shadowset were being merged and you
    added a third member, you would see the first two *both* in merge
    state, with the 3rd member as a copy target, but that's *not* what
    you see.

    You see a 2-member set with one as merging, and the 2nd as a copy
    target... Was there originally a third member (maybe on NADILA?)
    that was originally in merge state, but got dismounted before the
    merge completed? I think in this case, it show change the remaining
    member to "member" status, and the copy should proceed from it, so
    the status would resemble DSA520:, but maybe there's a bug if a
    copy is in progress at the same time as the merge, and you drop
    one of the "merging" disks, it doesn't change the status of the
    other one.

    P.S. I know who R. Daneel Steele is, and Gladia and Elijah, but
    who is Nadila? (It's been a while since I read any old Asimov.)


    --
    John

  4. Re: strange disk states

    In article , moroney@world.std.spaamtrap.com
    (Michael Moroney) writes:

    > >I'll post another message about the ultimate cause of the problem.
    > >Right now, I'm wondering how one member of DSA510: can be a copy target
    > >and the other member in the "merging" status. Shouldn't either no or
    > >both members be in the "merging" status?

    >
    > That state wasn't possible back when I was messing with shadowing. You
    > needed 2 or more full members to be in a merge state. It may be that
    > they've updated shadowing in such a way that a copy target can be a source
    > if reading from below the copy fence, otherwise no. If that is the case,
    > the normal need for a merge would apply, and I don't know how they'd
    > handle that.


    The shadow set in question has each member attached directly to (only) a
    VAX running 7.3 (VAXstation 4000/90 and VAX 4000/100A). (The ALPHA is
    running 7.3-2.)


  5. Re: strange disk states

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:

    >In article , moroney@world.std.spaamtrap.com
    >(Michael Moroney) writes:


    >> That state wasn't possible back when I was messing with shadowing. You
    >> needed 2 or more full members to be in a merge state. It may be that
    >> they've updated shadowing in such a way that a copy target can be a source
    >> if reading from below the copy fence, otherwise no. If that is the case,
    >> the normal need for a merge would apply, and I don't know how they'd
    >> handle that.


    >The shadow set in question has each member attached directly to (only) a
    >VAX running 7.3 (VAXstation 4000/90 and VAX 4000/100A). (The ALPHA is
    >running 7.3-2.)


    I missed that. That's old enough that I know it shouldn't do that.

  6. Re: strange disk states

    In article , helbig@astro.multiCLOTHESvax.de
    (Phillip Helbig---remove CLOTHES to reply) writes:

    > > That state wasn't possible back when I was messing with shadowing. You
    > > needed 2 or more full members to be in a merge state. It may be that
    > > they've updated shadowing in such a way that a copy target can be a source
    > > if reading from below the copy fence, otherwise no. If that is the case,
    > > the normal need for a merge would apply, and I don't know how they'd
    > > handle that.

    >
    > The shadow set in question has each member attached directly to (only) a
    > VAX running 7.3 (VAXstation 4000/90 and VAX 4000/100A). (The ALPHA is
    > running 7.3-2.)


    After the copy completed, both members went into the "merging" status.


  7. Re: strange disk states


    > > P.S. I know who R. Daneel Steele

    >
    > That's R. Daneel Olivaw (in THE CAVES OF STEEL, among other books)
    >


    It looks like there was some confusion here with Danielle Steel, the
    writer :-)

+ Reply to Thread