Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!wuarchive!sdd.hp.com!hplabs!hpda!hpcuhc!dhepner
From: dhepner@hpcuhc.cup.hp.com (Dan Hepner)
Newsgroups: comp.arch
Subject: Re: Re: Incremental sync()s and using disk idle time
Message-ID: <107340004@hpcuhc.cup.hp.com>
Date: 12 Mar 91 19:44:59 GMT
References: <1991Mar8.142031.9098@bellcore.bellcore.com>
Organization: Hewlett Packard, Cupertino
Lines: 34

From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)

>  I think I heard this argument before when operating systems started
>buffering i/o... I guess what you're looking for is MS-DOS, where you're
>sure how things work (slowly).

The most striking irritation of those who pioneered the usage 
of Un*x for for commercial applications has come because of some 
implementations which provided no way around such buffering.
Many of these offerings were still deficient well after the need 
for such had been established.

>  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.  Does your O_SYNC do 
the right thing with such a drive?  What about fsync(2)?  What, 
for that matter, happens when you write to a "raw disk"? 

 The only time I ever care is when doing something like
>database or T.P. where order counts in case of error.
>bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)

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.

Dan Hepner
Not a statement of the Hewlett Packard Co.