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

  1. Path: sparky!uunet!comp.vuw.ac.nz!zl2tnm!toyunix!don
  2. Newsgroups: comp.os.vms
  3. Subject: Re: Question about RMS and MSCP-pair
  4. Message-ID: <17080003@zl2tnm.gen.nz>
  5. From: don@zl2tnm.gen.nz (Don Stokes)
  6. Date: 4 Jan 93 14:53:49 GMT
  7. Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
  8. References: <1993Jan4.115621.29717@news.th-darmstadt.de>
  9. Distribution: world
  10. Organization: The Wolery
  11. Lines: 39
  12.  
  13. sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de (M. Gaertner, FRM, TH Darmstadt, Germany) writes:
  14. > I understand that MSCP-served disks (aka RQDX3) may do bad-block-revectoring
  15. > on the attached disk. I also understand that, when the original block
  16. > showes unrecoverable READ-errors, the "forced error flag" on the copied
  17. > block will be set.
  18. > What I don't understand is why the RMS then refuses to read the file 
  19. > where the forced error-block is in. It always returns the (correct) 
  20.  
  21. It's quite simple really.
  22.  
  23. If a block goes bad, you can find out in several ways:
  24.  
  25.     (1) You try to write to the block
  26.     (2) You try to read the block, and get the data off it after retries
  27.     (3) You try to read the block, but cannot persuade it to read.
  28.  
  29. In cases (1) and (2) all is dandy, you got what you want and the controller
  30. can revector the block so it's not a problem next time.
  31.  
  32. In case (3), the data is gone for good.  Sure, the controller can revector
  33. the block, but if you try to read the revectored block, you won't get what
  34. was originally written to it.
  35.  
  36. In this case, the system marks the block with a forced error flag.  This 
  37. tells the system that whatever was written to that block aint there anymore,
  38. and to treat an attempt to read it as an error, since you're probably going
  39. to barf on it anyway, or worse introduce bad data into your otherwise
  40. reliable (8-)) systems.
  41.  
  42. The only way to clear the forced error flag is to write to the block.  When
  43. you do this, the previous "data" is overwritten with good data, and the 
  44. block can be re-used.
  45.  
  46. Does that help?
  47.  
  48. --
  49. Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
  50. Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
  51. Victoria University of Wellington, New Zealand              +64-4-495-5052
  52.