Re: Shadow set problem finally solved

In article <10b5d716-18aa-4705-bec3-dc169725ada0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, tadamsmar <tadamsmar@xxxxxxxxx> writes:
On Mar 8, 5:22pm, George Cornelius wrote:
This thing really seems to be going nowhere. It sure seems to me that
this is a standard, pure-vanilla problem of a shadow set having a forced
error that VMS replicates on every shadow copy, something that's been
around since Phase I shadowing and RA series drives.

If that is the case, the solution is to overwrite the block in question.

You should, just to be thorough, examine [000000]BADBLK.SYS and if it
has any allocation, check its LBN's with $ DUMP/HEADER/BLOCK=C:0 .


[...] you can also do this:

$ create/fdl=sys$input JUNK.TMP001
area 0;allocation 1;contig yes;exact_positioning yes;position logical -
16578125
<terminate with CTRL/Z>

[...]

How do I look at BADBLK.SYS for a shadow set?

I supplied a $ DUMP command. But, never mind. I only mentioned it for
thoroughness. We already know in your case that the block is not allocated
anywhere.

How about doing this:

1. Break out a member.
2. Do an back/image on the member
3. init/eras the member
4. restore the image on the member
5. boot on the member, making it the only member of the shadowset.
6. merge the other disk into the shadowset

Yes, and if not a boot disk the following [after being certain nothing will be
writing to DSAn] would be more direct:

$ dismount member2
$ initialize/erase/system member2: dummy ! No special init command needed
$ mount/foreign/noassist/override=shadow_membership member2
$ backup/image/noalias DSAn: member2: ! Default init params are from source vol
$ dismount DSAn:
$ dismount member2:
$ mount/sys DSAn:/shadow=member2:/conf label ! /conf just in case .-2 failed
$ ! <add 2nd member later>

Even if it is a boot disk you may be able to do the above steps by booting
from CDROM.

My temp file technique solves the problem outright. There are no mounts and
dismounts; nor are there shadow copies.

Since it uses VMS to allocate the LBN into a temp file, it does not allocate
the LBN unless it is free. This means you do not have to worry that it can
destroy data in some random file.

Would that get rid of all these parity errors?

Both approaches do this. One is surgical; the other brute force.

It seems a little safer and easier (for me) than trying to write
blocks to specific LBAs.

Go for it. You seem to be a bit over your head here, and a procedure you
understand is much better than one that confuses you further.

--
George Cornelius cornelius A T eisner D O T decus D O T org
cornelius A T mayo D O T edu
.

Relevant Pages

  • Re: VMS analogue of FBSD and linux hier(7) man pages
    ... x ROSRVC x VMS V7.3-2 x MEMBER xmqqqqqqqqqqqqqqqqqqqj ... a full shadow copy. ...
    (comp.os.vms)
  • Re: Shadow set problem finally solved
    ... pure-vanilla problem of a shadow set having a forced ... error that VMS replicates on every shadow copy, ...  Do an back/image on the member ... It ran clean on the single disk. ...
    (comp.os.vms)
  • Re: Shadow set problem finally solved
    ... pure-vanilla problem of a shadow set having a forced ... you have to allocate the block somehow. ... init/erase a target drive, then back up to it from your master copy]. ... Break out a member. ...
    (comp.os.vms)
  • Re: Shadow set problem finally solved
    ... pure-vanilla problem of a shadow set having a forced ...  Do an back/image on the member ... and if not a boot disk the following [after being certain nothing will be ... My temp file technique solves the problem outright. ...
    (comp.os.vms)
  • Re: errors on shadow sets and their members
    ... Don't bother looking for errors on the shadow devices. ... %SYSMAN-I-OUTPUT, command execution on node C ... >a member of a shadow set. ...
    (comp.os.vms)