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