home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sgi / 13028 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.8 KB  |  64 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!munnari.oz.au!mips!mips!odin!fido!zola!zuni!anchor!olson
  3. From: olson@anchor.esd.sgi.com (Dave Olson)
  4. Subject: Re: updating bad block list on SCSI disk using fx
  5. Message-ID: <p5lvogo@zuni.esd.sgi.com>
  6. Sender: news@zuni.esd.sgi.com (Net News)
  7. Organization:  Silicon Graphics, Inc.  Mountain View, CA
  8. References: <1992Aug28.191401.29136@unixg.ubc.ca>
  9. Date: Sat, 29 Aug 92 03:05:20 GMT
  10. Lines: 52
  11.  
  12. In <1992Aug28.191401.29136@unixg.ubc.ca> laplante@ocgy.ubc.ca (Denis Laplante) writes:
  13.  
  14.  
  15. | I tried to use the fx command 'auto' to reformat a disk suspected of having
  16. | bad blocks.  The man page says
  17. |      auto Initializes a    new disk. The disk is formatted, a label is created
  18. |       and written to it, and it is exercised to detect and map out bad
  19. |       blocks.
  20. | Fx then printed 213 cryptic 2-line errors, all the same except for a block
  21. | number near the block in error, in the form:
  22. |   fx/auto/complete: warning - data mismatch
  23. |   fx/auto/complete: Error 0 -- Couldn't find bad block on track starting with \
  24. |     block 283590 after 2 tries
  25.  
  26. That means you either have bad cabling/termination problems, or a drive
  27. with extremely flaky firmware.  fx won't forward the bad blocks unless
  28. it is convinced that they are really bad; it isn't able to find the
  29. failing blocks when it goes to look for them.  You could use -r0 to
  30. suppress some of the retries, which might find some of them.
  31.  
  32. | 1- How likely are those 213 ignored bad blocks to come back and haunt me?
  33. |    Will these blocks just invisibly suffer from automatically recovered
  34. |    errors?  
  35.  
  36. They aren't really 'bad' in the sense of causing an error, but they
  37. aren't returning the same data that was written to them, at least
  38. some of the time, which is definitely going to cause problems!
  39.  
  40. | 2- Is there a way to log recovered SCSI disk errors, as a warning of trouble
  41.  
  42. Yes; use the /label/set/param menu to enable reporting of recovered
  43. errors; the kernel will print them, and syslogd will log them to
  44. /usr/adm/SYSLOG
  45.  
  46. | 3- What did I do wrong for the bad block list to not be updated?
  47.  
  48. There weren't any hard errors.
  49.  
  50. | 4- Is there a way to declare new bad blocks without losing data, and without
  51. |    I would guess that on an unmounted partition the following might do it:
  52. |      badblock/addbb
  53. |      debug/writebuf (the same block address now accesses a new disk sector)
  54.  
  55. As of 4.0.5, fx will attempt to read the data before forwarding the
  56. bad blocks on SCSI drives (it always has for other drive types), and
  57. if successful, will rewrite the data after the block is forwarded.
  58.  
  59. I'm not sure that will fix your problems though.
  60. --
  61. Let no one tell me that silence gives consent,  |   Dave Olson
  62. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  63.     Maria Isabel Barreno                        |   olson@sgi.com
  64.