Re: Shadow set problem finally solved
- From: tadamsmar <tadamsmar@xxxxxxxxx>
- Date: Mon, 24 Mar 2008 05:41:50 -0700 (PDT)
On Mar 14, 8:53 am, tadamsmar <tadams...@xxxxxxxxx> wrote:
On Mar 13, 7:04 pm, moro...@xxxxxxxxxxxxxxxxxxxxxxx (Michael Moroney)
wrote:
tadamsmar<tadams...@xxxxxxxxx> writes:
On Mar 13, 8:33=A0am,tadamsmar<tadams...@xxxxxxxxx> wrote:
It worked! =A0I finally got a clean ANAL/DISK/SHADOW!Opps, not quite there. It ran clean on the single disk. But when I
add the other disk to the shadowset it reported the 4 blocks with
errors. VMS does not want to give these up without a fight.
Did you get those errors from $ ANAL/DISK/SHADOWor from when theshadow
copy was taking place?
From theshadowcopy.
If the latter, those bad blocks may already be
gone.
Due to speed/synchronization issues, ashadowcopy doesn't blindly copy
blocks from the source to the target. It reads from the target and
compares them to the source. If different, the source is copied to the
target.
Now, if the target had 4 blocks marked as bad, they would have been
reported during the read. However, they would have been immediately
overwritten, and by now would be gone.
I guess you are saying that I got 4 read errors on the reads, but they
would have been overwritten, so that I would have never seen them
again.
Too late to confirm that idea on the disk that I have installed since
I erased it. But I will probably reinstall the old disks and send the
new ones back to the vendor. When I put the old disk in, it will be
carrying 4 "bad" blocks, so I could confirm your idea.
This did confirm for one of the disks that I suspected was good. You
log errors during the merge, but never again. ANAL/DISK/SHAD runs
clean.
On a disk that I suspected of having some bad blocks (the one that
probably started this whole problem), I still get a parity errors on
the ANAL/DISK/SHAD.
This seems to be an ironic situation. If I were not shadowing, I
could run the bad block utility on this disk and then use it without
problems.
But in a shadow set, it will always a parity error for ANA/DISK/SHAD.
I could use it, but with spurious errors being reported for every full
merge and spurious failure on every run of ANAL/DISK/SHAD.
I have a good disk to replace this bad one, but I wonder if there is
some way around this, so I could use this disk without all the
spurious error reports. I might want to keep the disk, it just has a
few bad blocks.
I forgot about that. If they're
reported by $ ANAL/DISK/SHADOW, I guess I don't know.
|
.
- References:
- Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: George Cornelius
- Re: Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: tadamsmar
- Re: Shadow set problem finally solved
- From: tadamsmar
- Shadow set problem finally solved
- Prev by Date: Re: Text files from VMS to Windows
- Next by Date: Re: Tripwire on OpenVMS Best Practices?
- Previous by thread: Re: Shadow set problem finally solved
- Next by thread: Re: Shadow set problem finally solved
- Index(es):
Relevant Pages
|