Re: Bad Shadow set member

That depens on how broken the disk was.

> But the other disk was broken, so no copy is even possible. Wouldn't it
> make sense for the shadowing software to mount the only available
> member?

Sure. Don't use /INCLUDE in that case.

>And even with a merge, the
> software is going to have to randomly pick one or the other disk
> anyway, right?

If you mean for copying the data, no. There's still a 'master' member,
but the handling in case of errors is different than with a full copy.
In the merge case any errors will be propagated from the bad to the
good member. The only thing that counts in such a case is that the
disk are equal in the end.

Jur.

AEF wrote:
Jur van der Burg wrote:
That's not a bug. You asked specifically for NO copy, and due to the
power outage a merge copy is required....

But the other disk was broken, so no copy is even possible. Wouldn't it
make sense for the shadowing software to mount the only available
member? If you had a one-member shadow set, you're saying it still
wouldn't mount because of the power outage? And even with a merge, the
software is going to have to randomly pick one or the other disk
anyway, right?

Perhaps you would like the /POLICY=REQUIRE_MEMBERS for mount so that
it insists on both members to be present.

I think that's exactly what the OP *doesn't* want.

AEF

Jur.

Tom Linden wrote:
On Sat, 09 Dec 2006 19:12:40 -0800, AEF <spamsink2001@xxxxxxxxx> wrote:

Tom Linden wrote:
On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@xxxxxxxxx> wrote:

"Tom Linden" <tom@xxxxxxxxxxxxxxxxx> wrote on 12/09/2006 09:31:17 AM:
[...]
Sorry, should have been more clear. The mount caommand issued manually
worked fine as below
MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -
SHADOW=($42$DKA1300:) COMMON

What I was puzzling over was the mount command from the startup file
that
had
both members listed failed. Why wouldn't mount, knowing that one member
had
failed, take corrective action and mount the working member. This seems
fundamental to me for a shadow set.
What was the error message???
Looking through my logs this is all I found

$ MOUNT
DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)
COMMON
%MOUNT-F-SHDWCOPYREQ, shadow copy required

Unless the above command is incorrect, this is a bug. If a member of a
shadow set fails,
the mount command should recover, otherwise have shadow sets

[...]

AEF



--Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

.

Relevant Pages

  • Re: Bad Shadow set member
    ... So I had to manually mount omitting the first member. ... Am I missing a qualifier? ... Automatically reconstructs a former shadow set to the way it was ...
    (comp.os.vms)
  • Re: Bad Shadow set member
    ... This is in the startup ... So I had to manually mount omitting the first member. ... disks than the entire shadow set. ...
    (comp.os.vms)
  • Re: Bad Shadow set member
    ... So I had to manually mount omitting the first member. ... Our usage of this was through a subroutine which was passed the ... mount the shadow set specifying JUST THE CURRENT MEMBER: ...
    (comp.os.vms)
  • Re: any way to dismount and remount this?
    ... I have a single-member shadow set as a temporary measure. ... > (The other member is an internal disk in another machine which is ... > cluster reboot in a week anyway, but still I would like to know.) ...
    (comp.os.vms)
  • Re: disk errors
    ... Phillip Helbig---undress to reply wrote: ... A while back, in one shadow set, one member appeared to have some ... Can I assume that this disk is beyond repair? ... should I expect errors if I mount it back into the shadow set? ...
    (comp.os.vms)