On Sat, 4 Dec 1999 12:10:37 -0500 (EST)  Greg Hudson wrote:

> I'm having an interesting problem on a non-NetBSD operating system
> (Solaris), but it should apply equally well to NetBSD, since it's the
> same FFS behavior as we're used to.  It's about Unix filesystem
> semantics.

Mmm ... we'll see :-)

> The problem is this: on certain machines here, we rewrite four
> configuration files at boot time using a shell script, by moving aside
> the old versions and blatting out new ones with "echo".  Sometimes if
> the machines boot uncleanly after this process, the files are found to
> have zero length.  I assume what's going on for each file is:
> 
> 	* The directory entry and inode for the new file are written
> 	  out as soon as the file is created.
> 
> 	* The file contents themselves are cached, and don't get
> 	  written out until some indeterminate time in the future.

The problem I have with this analysis is that any reads of these files
should be satisfied from the buffer cache too; it should not matter if
the data is on disk yet or not.

I just tested now on NetBSD and this is the case.  Even before the new
data is on the disk, userland programs that open the file through the
filesystem see the new data.

How about your new output is in fact still stuck in a shell stdio
buffer somewhere?

> 	* Suppose I write a little program which opens a file,
> 	  fsync()s it, and then closes it.  Will that be sufficient to
> 	  synchronously commit all previous writes?

Yes.  Blessed by the standards I think, although the standards say
confusing stuff like this for fsync(2):

    The fsync() function forces all currently queued I/O operations
    associated with the file indicated by file descriptor fildes to
    the synchronised I/O completion state. All I/O operations are
    completed as defined for synchronised I/O file integrity
    completion.

I have tested this on FFS on NetBSD (now, as I was curious) and on
HP-UX's HFS some years ago, and it worked both places.  I remain
dubious that getting from the filesystem buffer cache to disk is your
problem though.

(When testing this sort of stuff Tom Christiansen's "icat" program
that reads files from the raw disk when given an inode number is
really useful.  It's a little tedious to write it each time.)

> 	* With the fancy new soft update thing

... no idea.  Interested, but no idea. :-)

Regards,

Giles