home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lrw.com!leichter
- From: leichter@lrw.com (Jerry Leichter)
- Newsgroups: comp.os.vms
- Subject: re: Question about RMS and MSCP-pair
- Message-ID: <9301041627.AA20066@uu3.psi.com>
- Date: 4 Jan 93 15:05:09 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Distribution: world
- Organization: The Internet
- Lines: 55
-
-
- I discovered some oddity with RMS and MSCP-served disk, at least I
- think so. I understand that MSCP-served disks (aka RQDX3) may do
- bad-block-revectoring on the attached disk. I also understand that,
- when the original block showes unrecoverable READ-errors, the "forced
- error flag" on the copied block will be set.
-
- No; not quite. It's a question of "how bad" the original block went.
-
- If the original block went "only a little" bad, the data in it is recoverable
- using the ECC (error-correcting code) value stored in the sector. In that
- case, the revectoring logic - whether running entirely in the disk adaptor, or
- as part of the driver - calculates what the original data in the block was,
- attaches a new ECC value, and writes that to the new block. It does NOT set
- the "forced error" flag; all RMS (and your application) ever see is that some
- I/O operation took an unusually long time to complete.
-
- If the original block was BADLY damaged, however, the ECC does not contain
- sufficient information to recover. In that case, the new block is marked
- with the "forced error" flag, which indicates that it contains no useful
- data: The data was lost due to the original error. The "forced error" flag
- describes the (lack of) DATA in the block, not the block itself - it will
- remain set until you write to the block, at which point it will be cleared
- silently.
-
- BTW, the exact boundary between "recoverable" and "badly damaged" blocks
- varies with each disk and controller - it's mainly a matter of how large the
- ECC is. For current DEC disks, any error involving less than somewhere in the
- low hundreds of bits is recoverable. Some very cheap third-party drives are
- lost if more than 11 bits go bad.
-
- What I don't understand is why the RMS then refuses to read the file
- where the forced error-block is in. It always returns the (correct)
- error (xxx, forced error flag set). So why does the revectoring take
- place? I don't care if the file is unreadable because of read-errors
- or forced errors. Or asked different, why isn't RMS showing the file
- as it is with a warning about the damaged block?
-
- *RMS* does. The forced error return comes back only when you read the partic-
- ular block that has the error in it. A program, if it wishes, can ignore
- the error and continue to access the file. BACKUP does this, for example.
- Many simple programs don't.
-
- Can anybody give an explanation to me?
-
- Oh, I know that revectoring bad blocks on the controller-level has
- it's advantages and I like the concept with the forced error flag BUT
- I don't like RMS's handling of these blocks.
-
- RMS is doing the only thing it possibly can with these blocks. Your problem
- is with the PROGRAMS that call RMS. (Note again that, whatever RMS, the
- drivers, the programs, etc., may do, the data originally "under" the forced
- error is gone.)
- -- Jerry
-
-