shadowing and bad blocks

[Ian Miller.]

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?

[Uwe Zessin]

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.]

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.

[Uwe Zessin]

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]

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

[John Gillings]

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.

[John Gillings]

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)

[Robert Brooks_1]

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]

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

[David B Sneddon]

$ ANALYZE/DISK/SHADOW

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

Dave

[Ian Miller.]

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.

[Jim_McKinney]

> "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?