Operating System - OpenVMS
1828064 Members
2560 Online
109974 Solutions
New Discussion

shadowing and bad blocks

 
Ian Miller.
Honored Contributor

shadowing and bad blocks

VAX/VMS V7.1. DSSI disks. Host based shadowing.
If one disk in a shadow set (with two members) reports bad blocks have been successfully replaced in the error log then is everything OK?
____________________
Purely Personal Opinion
11 REPLIES 11
Uwe Zessin
Honored Contributor

Re: shadowing and bad blocks

I'd say: yes.

It is my understanding that OpenVMS volume shadowing has "bad block repair code" that can retrieve data from the other shadowset member when it encounters a non-correctable read error on one member.

Or was this a simple bad block replacement _within_ the disk drive that happens on a write operation?
.
Ian Miller.
Honored Contributor

Re: shadowing and bad blocks

The bad block replacement reported in the error log was within the drive. So a block was written, encountered an error and was replaced by another within the drive.

I expect its fine but its a business critical [and neglected :-( ] system so I thought I better check.
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: shadowing and bad blocks

I've found DSSI disks to be pretty solid, even the first generation.

Does V7.1 have a way to compare both member? I am afraid not, but you might call HP's support - if I remember correctly, they have a separate tool to compare shadowset members.
.
Jan van den Ende
Honored Contributor

Re: shadowing and bad blocks

Ian,

AFAIK, DSSI has a Bad Block Replacement Area (one of the reasons that the formatted size is rather less than the raw drive size).
If a bad bloch is detected BY THE DRIVE, then that block gets re-mapped from the BBRA, and the drive is again presented as flawless. The only issue that remains is the extra head movements where none look needed - but the drive knows.

hth

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: shadowing and bad blocks

Ian,

You need to be careful here... If the shadowset is reduced to a single member, and a bad block is detected (block READ), the normal controller replacement is done, but since there's no "good" block to recover the data, the block is marked as "bad":

"FORCEDERROR, forced error flagged in last sector read"

When/if the shadow set is reformed with additional members, the forced error flag is propagated to the new member on a full copy (hmmm, interesting thought, I wonder what happens on a minicopy? remember the block hasn't been written - in theory the good data could be propagated to the revectored block, but since you're V7.1, I guess that's all academic).

So, if you can read the block without getting the FORCEDERROR I'd say you're OK.

The moral of the story is to never reduce your shadow sets to less than 2 members.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: shadowing and bad blocks

Oh, almost forgot...

If you have really important data that's not accessed very often, it's probably also a good idea to force a merge every now and then (V7.3-2+ SET SHADOW/DEMAND_MERGE). This will read every block on every member, thus forcing any latent bad blocks to be revectored and repaired.

(maybe during off hours)
A crucible of informative mistakes
Robert Brooks_1
Honored Contributor

Re: shadowing and bad blocks

John wrote . . .

If you have really important data that's not accessed very often, it's probably also a good idea to force a merge every now and then (V7.3-2+ SET SHADOW/DEMAND_MERGE). This will read every block on every member, thus forcing any latent bad blocks to be revectored and repaired.

----

If you follow John's reasonable advice, please remember to temporarily turn off HBMM if it's in use on the virtual unit that you plan to merge on demand. If you don't, the merge will be driven by the existing bitmap, rather than by reading all the blocks on the shadow set members.


-- Rob
Wim Van den Wyngaert
Honored Contributor

Re: shadowing and bad blocks

Until now, all bad blocks on our shadowed disks were recovered by the shadowing software / disk software. And we have had disks with many many bad blocks.

To my knowledge, there is nothing to report the differences between 2 disks while they are in use. We once had to force a shadow copy because due to a shaodwing bug the 2 disks were not equal.

Wim
Wim
David B Sneddon
Honored Contributor

Re: shadowing and bad blocks


$ ANALYZE/DISK/SHADOW

will do a compare of a "live" shadowset.
Don't know which version introduced this feature.

Dave
Ian Miller.
Honored Contributor

Re: shadowing and bad blocks

There has been a full shadow copy onto that disk since I started this thread. The other member disk has reported no errors.

Using DFU SEARCH/LBN I had discovered that the bad blocks where in a database file so wanted to double check things worked as I thought.

The database would have requested those blocks where written, one of the disks detected bad blocks and revectored the LBN to a new place on disk and wrote the data there. End result two disks with the same contents of those LBNs.

Mini merge, ANAL/SHADOW etc don't exist in VAX VMS V7.1.
____________________
Purely Personal Opinion
Jim_McKinney
Honored Contributor

Re: shadowing and bad blocks

> "FORCEDERROR, forced error flagged in last sector read"

> When/if the shadow set is reformed with additional members, the forced error flag is propagated to the new member on a full copy


My experience, through VMS 7.3, has this particular operation failing. The read of the source block fails - since the block can't be read the shadow copy aborts. That flagged block has to be re-written or re-vectored before the shadow copy can complete. Perhaps this behavior is changed with the current version of VMS?