Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!emory!gatech!usenet.ins.cwru.edu!eagle!csduts1!xxremak From: xxremak@csduts1.lerc.nasa.gov (David A. Remaklus) Newsgroups: comp.arch Subject: Re: Re: Incremental sync()s and using disk idle time Message-ID: <1991Mar12.184358.3898@eagle.lerc.nasa.gov> Date: 12 Mar 91 18:43:58 GMT References: <1991Mar8.142031.9098@bellcore.bellcore.com> <107340003@hpcuhc.cup.hp.com> Sender: news@eagle.lerc.nasa.gov Reply-To: xxremak@csduts1.UUCP (David A. Remaklus) Organization: NASA/Lewis Research Center, Cleveland Lines: 53 In article <107340003@hpcuhc.cup.hp.com> dhepner@hpcuhc.cup.hp.com (Dan Hepner) writes: >From: rbw00@ccc.amdahl.com ( 213 Richard Wilmot) > >>because although they don't insist on flushing out all database changes >>to disk on termination of each transaction, they RELY ON NOT HAVING ANY >>UNCOMMITTED (UNFINISHED) CHANGES WRITTEN TO DISK. That is, if the system >>crashed, then an advanced transaction system would expect to see NONE >>of the changes made by any incomplete transactions from before the crash. > >Agreed. >The drives we're familiar with do in fact support a synchronous access, >either by request or "setting the controller in that mode". For all >database usage, we intend that any controller caching be bypassed. This >does however leave an assumption that "somebody else" must be able to >make use of that caching, because OLTP sure can't. It's also worth >noting that a battery backed up controller cache might turn out to >be vastly more interesting. > Amdahls latest update to the 6100 Caching disk controller includes just that, battery backed-up cache memory for disk writes (as does big blues 3990 controller). Before this battery supported cache (called Non-Volatile Store), all writes were automatically write-back (I/O completion was not signalled until the data was written to the disk). >>If a file system cannot accommodate this kind of use then the transaction >>system implementors will again be forced into using raw I/O - to >>avoid the file system. >>Alas, RAW I/O is still the answer for most database/transaction systems. > >This is perhaps the biggest trap of all. Using raw IO has nothing >to do with the behavior of a disk controller unless one has specifically >modified one's kernel to do something special, such as post all >raw writes as synchronous writes. The default behavior will be for >raw writes to be treated like any other write; the disk controller >doesn't know or care where this write came from. > The latest release of the UTS (Amdahl mainframe U*ix) includes a new file system type that enables an application to specify via fcntl calls that I/O to a particular file is to be synchronous, ie, control is not returned until the data has successfully been written to the I/O device. Normal U*ix system calls to normal U*ix files can be used for the DBMS files. This feature was specifically added for DBMS support. ( stuff deleted ) -- David A. Remaklus Currently at: NASA Lewis Research Center Amdahl Corporation MS 142-4 (216) 642-1044 Cleveland, Ohio 44135 (216) 433-5119 xxremak@csduts1.lerc.nasa.gov