Re: Shadow set problem finally solved
- From: tadamsmar <tadamsmar@xxxxxxxxx>
- Date: Wed, 12 Mar 2008 06:59:22 -0700 (PDT)
On Mar 8, 5:22 pm, BEGINcornel...@xxxxxxxxxxxxxxxx (George Cornelius)
wrote:
In article <fdm2t39vc3osaija6bflusngdeljh1g...@xxxxxxx>, Pete <None@xxxxxxxxxxxx> writes:
On Thu, 6 Mar 2008 17:09:44 -0800 (PST), tadamsmar
<tadams...@xxxxxxxxx> wrote:
Maybe if you posted all the messages returned from the ana/disk/read
someone might be able to pick somethin out.
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 .
If your block's not there, and if it's not already in some other file,
you have to allocate the block somehow.
I've done it in the past by extending an existing zero-length file with
some Macro code and an allocation XAB, something that's not too difficult
once you home in on the correct settings, as in
ExtendALQ=1
StartLBN=16578125
ExtendXAB: $XABALL ALQ=ExtendALQ,AOP=<CTG,HRD>,ALN=LBN,LOC=StartLBN
But 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>
Note that this seems to work as long as the cluster containing the block
is available, in which case the starting point will be as much as
cluster_size - 1 earlier than was requested.
Once you have the block allocated into a file, say 0 blocks in use of
N blocks allocated, write to the file, making sure there is enough
data to overwrite the bad block. Remember that you should write at
least one cluster's worth of data even though you only asked for one
block to be allocated.
After redoing the shadow copy and checking that your errors have, in
fact, gone away and everything is stable, you can delete the temporary
file.
[I haven't done this for a long time, so it's from memory. If this fails,
init/erase a target drive, then back up to it from your master copy].
--
George Cornelius cornelius A T eisner D O T decus D O T org
cornelius A T mayo D O T edu
How do I look at BADBLK.SYS for a shadow set? I have broke a member
out of the shadowset and mounted it foreign before, but I don't get
any useful info that way. ANAL/MEDIA seems to be completely
independent of the shadowset algorithm for locating bad blocks. Are
you sure a *shadow set* uses BADBLK.SYS? If so, how do I read it?
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
Would that get rid of all these parity errors?
It seems a little safer and easier (for me) than trying to write
blocks to specific LBAs.
If this procedure would work, do I need any qualifiers on init/erase
or are the defaults just reproduce the disk parameters that are
already there?
.
- Follow-Ups:
- Re: Shadow set problem finally solved
- From: George Cornelius
- Re: Shadow set problem finally solved
- From: George Cornelius
- Re: Shadow set problem finally solved
- References:
- Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: Pete
- Re: Shadow set problem finally solved
- From: George Cornelius
- Shadow set problem finally solved
- Prev by Date: Re: Apache performance problem
- Next by Date: Re: Proof that macintosh is better than VMS
- Previous by thread: Re: Shadow set problem finally solved
- Next by thread: Re: Shadow set problem finally solved
- Index(es):
Relevant Pages
|
