home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / misc / 2061 < prev    next >
Encoding:
Text File  |  1992-08-14  |  1.6 KB  |  36 lines

  1. Newsgroups: comp.os.ms-windows.misc
  2. Path: sparky!uunet!wupost!gumby!destroyer!fmsrl7!eccdb1.pms.ford.com!vscarafi
  3. From: vscarafi@eccdb1.pms.ford.com (Vincent F. Scarafino)
  4. Subject: Re: SMARTDRV for Windows 3.1
  5. Message-ID: <BszDLM.G8u@fmsrl7.srl.ford.com>
  6. Originator: news@pms001
  7. Sender: usenet@fmsrl7.srl.ford.com (0000-Admin(0000))
  8. Organization: Ford Motor Co.
  9. References: <1992Aug12.233533.8605@dmp.csiro.au>
  10. Date: Fri, 14 Aug 1992 15:56:05 GMT
  11. Lines: 23
  12.  
  13. annef@dmp.csiro.au (Anne Foxworthy) writes:
  14. > Perhaps I worded my original post a little strongly. I do think SmartDrive
  15. > write caching is a good thing _in general_. What I was concerned about were
  16. > the number of people who seemed to believe the original person who asked
  17. > about SmartDrive caching was being overly fussy, without apparently
  18. > thinking about the various (admittedly few) situations in which write
  19. > caching could be a major problem.
  20.  ......
  21.  
  22. Programs that do proper transaction support *require* the assurance that at
  23. least a minimal amount of data be safely written to a log (in such a way as
  24. to survive the loss of power) *before* they can acknowledge to the application
  25. that a transaction has been committed.  Otherwise there is an integrity
  26. problem.  Having the data in a write cache located in volatile memory doesn't
  27. meet design requirement.  Programs that haven't been modified to use the
  28. smartdrv entry point to produce the physical write can solve the problem
  29. by putting the log file onto a logical drive that has write cache turned
  30. off.  Note that the data base itself need not be on a non-write-cached
  31. drive, only the log.
  32.  
  33. Vince
  34.