Xref: utzoo comp.protocols.nfs:1917 comp.arch:21369
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdahl!JUTS!rbw00
From: rbw00@ccc.amdahl.com (  213  Richard Wilmot)
Newsgroups: comp.protocols.nfs,comp.arch
Subject: Re: Incremental sync()s and using disk idle time
Summary: Beware transaction systems.
Keywords: transaction systems, database processing
Message-ID: <d1dP02yR05D=01@JUTS.ccc.amdahl.com>
Date: 11 Mar 91 18:06:59 GMT
References: <28975@cs.yale.edu> <PCG.91Feb28195347@odin.cs.aber.ac.uk> <PCG.91Mar4210505@aberdb.cs.aber.ac.uk> <1991Mar5.223443.21187@ns.uoregon.edu> <1991Mar6.003008.9131@bellcore.bellcore.com> <1991Mar7.115154.4820@hq.demos.su> <1991Mar8.142031.9098@bellcore.b <KIN
Reply-To: rbw00@JUTS.ccc.amdahl.com (  213  Richard Wilmot)
Followup-To: comp.arch
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 49

In article <KINCH.91Mar9170121@no31sun.csd.uwo.ca> kinch@no31sun.csd.uwo.ca (Dave Kinchlea) writes:
>In article <10773@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>
>
>   Sometimes I think we need a Coalition to Stamp Out `Smart' I/O Devices,
>   -- 
>   In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
>   Berkeley, CA		Domain:	torek@ee.lbl.gov
>
>Actually I have been having quite the oposite thoughts lately. It seems to me
>that it would be highly advantagous (in the general case) to take all of
>the filesystem information out of the kernel and give it to the I/O controller.
>
>I don't just mean what requests are satisified first (although this would 
>be one of its tasks) but one which also supports an abstract filesystem. 
>This would take out alot of logic from the kernel, it needn't spend time
>through namei() et al. let an intellegent controller do that. 
>
>Am I missing something important here, other than the fact that no operating
>system I am aware of has a concept of an abstract filesystem (except at 
>the user level). There is still some logic needed re virtual memory and 
>possible page-outs etc but I think it could work. Any comments?
>
>cheers kinch
>Dave Kinchlea, cs grad student at UWO (thats in London Ontario)

I see some problems with transaction processing systems which rely on
being able to absolutely control the timing of disk writes. Some (the
more efficient ones only need do this for their logs/journals) while others
want to flush out all changes made by a transaction and ensure that
it all got there before sending a terminal reply or dispensing the
ATM cash. There may be more problems with the more efficient systems
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.
 
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.
They keep their own set of buffers and file structures. It need not be
so if the file system incorporates the semantic needs of transaction/database
systems.
-- 
  Dick Wilmot  | I declaim that Amdahl might disclaim any of my claims.
                 (408) 746-6108