Uses for access time, stuff in inodes

[It takes a clear mind to make it]

In article <12606 at tut.cis.ohio-state.edu> karl at triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>daveb at llama.rtech.UUCP says...
>   It would be nice if there were some way for
>   O_SYNCed files to avoid [2 writes/call]: maybe just defer the
>   access/mod time write until the file is closed.
>
>I would disagree.  If data blocks are updated but the inode is left
>in-core-only, what value have I gained by using O_SYNC?  If the system
>crashes right now, with half a megabyte of data written, but no record
>of the changes to the inode yet out to disc, O_SYNC has become
>useless.
>
>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.

The specific example we have in mind is this.  There is a 1M file lying
around, within which we are doing seeks and read and writes to perform
updates (as you might imagine this is DBMS activity).  We don't give a
hoot about the access/mod time on the file, but we care a lot that the
data actually makes it to the disk.  That extra disk i/o can cut your
throughput in half, which is not acceptable.

It would also be perfectly acceptable to have an additional system call
that explicitly said, "I am extending this file to this length, get the
pages and write the inode to disk."  To a certain extent, this would be
a generalization of th existing BSD ftruncate call.

-dB

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