home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / ibm / pc / misc / 16048 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.0 KB

  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!brunel!concurrent.co.uk!nnw
  2. From: nnw@concurrent.co.uk (Neil Watson)
  3. Newsgroups: comp.sys.ibm.pc.misc
  4. Subject: Re: Stacker ate my hard disk again. : ( help....
  5. Message-ID: <1992Dec21.103310.6949@concurrent.co.uk>
  6. Date: 21 Dec 92 10:33:10 GMT
  7. References: <92351.29836.J056600@LMSC5.IS.LMSC.LOCKHEED.COM> <1992Dec16.211411.16924@gn.ecn.purdue.edu>
  8. Sender: usenet@concurrent.co.uk (NetNews System)
  9. Organization: Concurrent Computer Corporation, Slough, England
  10. Lines: 44
  11. Nntp-Posting-Host: bugs.concurrent.co.uk
  12.  
  13. In article <1992Dec16.211411.16924@gn.ecn.purdue.edu> mechalas@gn.ecn.purdue.edu (John P. Mechalas) writes:
  14. >In article <92351.29836.J056600@LMSC5.IS.LMSC.LOCKHEED.COM> J056600@LMSC5.IS.LMSC.LOCKHEED.COM writes:
  15. >>
  16. >>Aye, 'tis true that the "three-fingered salute" in the middle of an app will
  17. >>giving you the "Updating allocation map..." message.  I've also encountered
  18. >>a "volume damaged" (aka "you should have backed up your hard drive, dummy)
  19. >>error on doing so--twice.  After the second time I scrapped Stacker and
  20. >>have had no more bad sectors arise (version 2.0).
  21. >
  22. >>What happens when a program hangs up, though?  You can't exit normally and
  23. >>gracefully.  You have no choice but to reset the machine.  I always tried to
  24. >>avoid needing to turn the machine off while programs were actively running,
  25. >>but it wasn't possible 100% of the time.
  26. >
  27. >I have programs hang all the time on me...and I am constantly rebooting 
  28. >while on a Stacker volume.  As long as the app in question wasn't in the middle
  29. >of a read/write exercise, you are okay.  
  30.  
  31. I think that John's last sentence is the key: as long as you
  32. don't reboot in the middle of a write (or before the write gets done, if
  33. you're using caching) then you'll probably not do any _serious_ damage.
  34. I presume that if you've updated a file (and completed the update), but
  35. not closed it, then the file is OK, its just the allocation information
  36. that is inconsistent (I seem to recall that some parts of UNIX - I'm
  37. thinking of NFS - only update the file information on close as well).
  38.  
  39. I suspect that MOST applications don't actually hang up (often) halfway
  40. through a write, and that, because of this, we (collectively) don't
  41. OFTEN see the "corrupted" flavour of failure (or write protection as
  42. stacker does it). When you're writing to a file, then you're in the
  43. commonly executed DOS code (however good that is....) and that it works
  44. most of the time. I also suspect that unless you end up completely
  45. corrupting memory, then even when a program is looping (read "hung"),
  46. then its likely that the timer interrupts that drive cache writes get
  47. executed still, so it probably still works. Maybe we should all be
  48. switching off write caching in any case....?
  49.  
  50. Neil.
  51.  
  52. -- 
  53. Neil Watson, ESDG Product Support, Concurrent Computer Corp
  54. G0BLD        227 Bath Road, Slough, Berks, SL1 4AX, England
  55.              Phone: (+44) 753 513360  FAX: (+44) 753 513303 
  56. (nnw@slough.ccur.com, nnw@concurrent.co.uk or 100021,3041 @ Compuserve)
  57.