home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / ibm / pc / hardware / 24030 < prev    next >
Encoding:
Text File  |  1992-09-11  |  1.5 KB  |  36 lines
  1. Newsgroups: comp.sys.ibm.pc.hardware
  2. Path: sparky!uunet!dcatlas!joet
  3. From: joet@dcatlas.dot.gov (Joe Trott)
  4. Subject: Re: Cache questions
  5. Message-ID: <1992Sep11.193140.4784@dcatlas.dot.gov>
  6. Organization: U.S Dept. of Transportation
  7. References: <1992Sep7.193149.23396@newstand.syr.edu>
  8. Date: Fri, 11 Sep 1992 19:31:40 GMT
  9. Lines: 25
  10.  
  11. ldstern@rodan.acs.syr.edu (Larry Stern) writes:
  12.  
  13. >2 questions about caches, please:  first, is it really necessary
  14. >to flush the cache (or wait several seconds) before turning
  15. >off the computer? 
  16.  
  17. Yes!  If you don't, data that has been written to the cache but not yet to
  18. disk will be lost.  It is possible to corrupt whole files (not just lose
  19. individual recods) this way.  Maybe worse, if the FAT needs to be updated.
  20.  
  21. >... And second, why does the cache have to be disabled
  22. >before defragmenting the hard disk?
  23.  
  24. A lot of defragging software directly accesses the disk at the sector
  25. level.  Disk caches may hide this information.  May.  What they will 
  26. _certainly_ do is prevent the safety features in most defragging programs
  27. from working.  Supposedly, if a good defragger is interrupted (even by
  28. power failure), there will be no data loss.  With a disk cache, however,
  29. it is likely that the FAT will be left describing a layout that is only
  30. incidentally related to the actual layout of your disk.  This is because
  31. the software is _always_ busy, and caches typically write in idle time
  32. (unless they are full).  This means you could have a[n almost] full cache of
  33. unwritten data (including FAT changes!) that could be lost.
  34.  
  35. -JTT
  36.