Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!moss From: moss@cs.umass.edu (Eliot Moss) Newsgroups: comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: Date: 15 Mar 91 14:08:37 GMT References: <1991Mar8.142031.9098@bellcore.bellcore.com> <107340004@hpcuhc.cup.hp.com> <3257@crdos1.crd.ge.COM> Sender: news@dime.cs.umass.edu Reply-To: moss@cs.umass.edu Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 25 In-reply-to: davidsen@crdos1.crd.ge.COM's message of 13 Mar 91 14:51:25 GMT I would like to make a small observation here: Insuring that things are done in a particular ORDER is not the same as insuring that they are done NOW. Sync features address the latter need without directly addressing the former. I think this may be suboptimal. For example, when writing a log, it may be important (to the recovery code) that it be written in order ALL THE TIME, but it only needs to be forced (synced) at particular times (checkpoints, say, or possibly commit points (there are MANY variations on database resiliency techniques)). On a slightly different note, there are certainly occasions where a database application may need to read a number of records and does not care about the order in which they are delivered. Having a smart system that allows MANY oustanding read requests and satisfies them in an order that is most efficient at the low level is also a good idea. -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu