Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: <3268@crdos1.crd.ge.COM> Date: 15 Mar 91 16:52:14 GMT References: <1991Mar8.142031.9098@bellcore.bellcore.com> <107340004@hpcuhc.cup.hp.com> <3257@crdos1.crd.ge.COM> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 54 In article moss@cs.umass.edu writes: | 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. If you need A to be written before B you would have to do a SYNC after A, true. If you were able to promise that writes from a single process would be done in order, without SYNC that might be all you need. While I can visualize a simple way to do this, I can't claim to have seen it implemneted in an interface to a controller. What needs to be done is to add one i/o request from a process to the queue, and either prevent any other i/o from that process from being queued, or force it to be later in the actual service queue. This means keeping track of the order in which things will be done. | 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. And unless your implementation writes in exactly one sector blocks (highly non-portable to other devices), some writes will span sectors, heads, and cylinders, even if your disk allocation is contiguous. This means there are lots of interrupts which can be handled by the controller. I would seem that logical i/o which spans several physical i/o could be done by the controller, reads could be ordered by the controller as long as all requests get services in one pass through the queue, and that many writes can be done in arbitrary order. A way to sync is absolutely required, and that some way to order writes is needed. It's not clear to me if that means writes by a process to all files need to be ordered or writes to just each individual file. In any case this can be insured by use of sync. Some of the systems I check spend more time waiting i/o than in the kernel, and have no idle CPU to measure. Anything which will make the i/o faster is great, and if it save some CPU for the user processes, that's a bonus. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"