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.

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

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.)

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.

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.

> > 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 :-)