home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20312 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  3.2 KB

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