Subject: fsync() fails under NFS, right?

From: [email-masked]
Date: Fri, 10 Sep 1999 14:36:00 -0400

Greetings, brave NFS trailblazers!

I have to ask you for a definitive confirmation or
refutation of the following sad observation:

fsync() (2) fails under NFS.

Why ask: I implemented a simple and robust
transactional layer abstraction, called bedrock,
for the NECI Intermemory project -- see
www.intermemory.org.  We currently finish the
paper (perhaps for USENIX), and the code will be
GPL'ed on the web.  

As a part of the bedrock spec, we had to disallow
remote files as the bedrock files (we currently
rely on files, raw partitions will come later...
if ever.:-)  

The transactional _commit_ is traditionally
implemented as "sliding in" a _superblock_ once
the rest is ready for enabling.  It is vital that
the commit reports success ONLY when the
superblock write actually ended up on disk.  On
UNIX, fsync() is supposed to do just that.

However, if the file if NFS mounted, fsync LIES.
:-)  It reports success while the file was just
too huge to be written to any, even Martian,
disk.  Why can't NFS make fsync() report an
"undefined" status instead of lying blatantly?

Other fine points discovered while battling the
lying NFS fsync(): detecting a remote system
status is difficult under unix/Linux.  I use GNU
fileutils now, which are idiosyncratic, heavily
system-specific, etc.

Overall, it is vital for transactional processing
to be able to detect whether a file system
supports fsync(), and so the new NFS must have
fsync() operate correctly or have a way to report
it's unreliable.

Am I right in any of the above?  ;-)

-- 
Cheers,
Alexy V. Khrabrov -- www.suffix.com -- [email-masked]