Re: Bad Shadow set member

On Sun, 10 Dec 2006 04:36:57 -0800, Jur van der Burg <"vdburg at hotmail dot com"> wrote:

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.

In my case bad meant dead, and that is the point. When the system rebooted
the the good member would not mount, but as i explained I had to manually
mount it, which seems to me to be a flaw in the concept since the whole
purpose of shadowing is to provide a higher degree of disaster tolerance..


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/




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

Relevant Pages

  • Re: Sizing up Disks with Shadowing
    ... Not as soon as the initial shadow copy is ready at least, ... the master. ... member being added to a 2 member set), data is read from either of the two ... place without the need to lock disk blocks or block I/O, ...
    (comp.os.vms)
  • Re: Bad Shadow set member
    ... That depens on how broken the disk was. ... > make sense for the shadowing software to mount the only available ... If you mean for copying the data, no. There's still a 'master' member, ... If you had a one-member shadow set, ...
    (comp.os.vms)
  • Re: Unpleasant Disk Shadowing Surprise
    ... Are the shadow members both internal disks in the ... or are they on an external controller? ... one disk in a shadow set started ... bad member. ...
    (comp.os.vms)
  • Re: Sizing up Disks with Shadowing
    ... Not as soon as the initial shadow copy is ready at least, ... A "master" member of a shadowset is only meaningful during a merge ... place without the need to lock disk blocks or block I/O, ...
    (comp.os.vms)
  • Re: Shadow set problem
    ... B comes up, its disk gets overwritten by a full copy from A, losing the ... , one node would come up quick enough to mount it before all the members were MSCP served to all nodes. ... another node would mount it and a full shadow copy would result. ...
    (comp.os.vms)