Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Re: Incremental sync()s and using disk idle time
Message-ID: <3257@crdos1.crd.ge.COM>
Date: 13 Mar 91 14:51:25 GMT
References: <1991Mar8.142031.9098@bellcore.bellcore.com> <107340004@hpcuhc.cup.hp.com>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 51

In article <107340004@hpcuhc.cup.hp.com> dhepner@hpcuhc.cup.hp.com (Dan Hepner) writes:
| From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)

| >  As long as there's a working sync or other means for my process to do
| >ordered writes in that less than one percent of the time when I care, I
| >am delighted to have things done in the fastest possible way the rest
| >of the time.
| 
| Unless your kernel vendor has provided some non-ordinary behavior
| for you to deal correctly with buffered disk drives, you're back
| in the same boat of users before O_SYNC.  

  O_SYNC, fsync, whatever. I don't consider having system calls work to
be "non-ordanary behavior." I said in the posting you quoted that there
has to be a way to insure an i/o is complete, and you seem to be saying
the same thing as if you were disagreeing with me.

| It might be worth pointing out that your mix, namely 99% something
| else, and 1% this kind, is a direct opposite of a lot of people,
| whose usage is 99% this kind, and 1% things which it is ok to
| indefinitely buffer.  Agreed, not many of them post to the net.

  Less than it appears. When doing a transaction, you might do something
like this:

	save old records (log file or whatever)
	SYNC
	lock records
	update records
	SYNC
	delete log or whatever (ie mark done)
	SYNC
	report as complete

  Note that this seems to be groups of i/o with SYNC points, and that if
I write five records, I should care what order the writes are done as
long as they are *all* done when the SYNC returns. And if I care about
order of record writes, then I should put in a SYNC here and there, no?

  Even on a system used for lots of TP, there are a lot of i/o which can
be buffered as long as you have a way to checkpoint and insure that all
changes are complete. And quite honestly I believe that a lot of
existing database and TP software makes assumptions which standard UNIX
(and other systems) don't always meet.

  I am using SYNC to represent any system call forcing block until i/o
complete, be it sync, fsync, O_SYNC, etc.
-- 
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"