Uses for access time (O_SYNC)_

[It takes a clear mind to make it]

In article <14470 at brl-adm.ARPA> urbsdc!preece at uunet.uu.net (Scott E. Preece) writes:
>From: (me)
>> >I tend to think that O_SYNC is specifically intended for those folks
>> >who are explicitly willing to put up with the performance hit of 2
>> >physical writes/call.
>> 
>> OK, then you write the inode when the file size changes, and update the
>> mod/access time at close.  Maybe you have O_SYNC work this way if an
>> additional (or alternative) option, say O_FASTSYNC was provided.
>----------
>Maybe the semantics should be separated, so that data can be written
>synchronously and control information asynchronously.  I understand your
>problem and can see that many people would not care about the updating
>of the times; on the other hand, many people WOULD care, too.  If, for
>instance, you had a data distribution daemon that only did its thing
>when it noticed that the file had changed, you would want to make sure
>that any change ended up in a mod time update.  it may not be your
>problem, but it is somebody's problem.

As I've outlined the operation of the "fast sync" above, these daemons
would continue to work.  The access and mod times *are* being updated,
and are visible to programs running on the machine.  They are just not
guaranteed to be written to disk.  Thus, if the machine crashes, the
contents of the file would be recoverable, but the access/mod times
might not be right.  That is still a lot better off than the traditional
non-sync operation.  

I'm not ruling out or denying at all the validity of totally-totally
synced i/o.  But there are less expensive ways to deal with a very
significant subset of the problems that desire it.

-dB
{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb at rtech.uucp