Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!mips!decwrl!sgi!llustig!objy!objy!peter
From: peter@objy.objy.com (Peter Moore)
Newsgroups: comp.protocols.nfs
Subject: NFS writes and fsync().
Message-ID: <1990Oct9.152612@objy.objy.com>
Date: 9 Oct 90 22:26:12 GMT
Sender: news@objy.com
Reply-To: peter@objy.com
Organization: Objectivity Inc.
Lines: 39


	My apologies if this is FAQ material, but I just have to know.

There are is a (somewhat) new product out that is supposed to speed up
NFS by cacheing NFS writes in a (somewhat) non-volatile cache.  The
advertisement states that the NFS protocol requires that NFS-write
requests not return until the data has actually been written to disk,
i.e. only after the equivalent of a UNIX fsync() on the file.  Since
this is a EXPENSIVE operation, they get a significant speed up of NFS by
keeping a write-back cache with some sort of battery backup up, and
just lie to the kernel that data has been synced.

Given that the above description is in roughly the same neighborhood
of the truth (it has come through a noisy channel, me).  I have to know:
WHY ON EARTH DOES NFS REQUIRE THE FSYNC ON WRITES?  Without that
requirement, we could the effect of this cache board by just not
calling fsync().

Now whenever I see something ugly in NFS, it usually comes from the
stateless requirement.  But the only state dependent reason I can see is:

    Process P on machine A writes to machine B

    machine B crashes before the write is synced to disk

    machine B recovers

    Process P does another write, dependent on the first succeeding.
    This second write does succeed and now we have inconsistent data.

But in real life, I have seen situations vaguely like this, and the
writing process gets a `stale NFS handle' error.  So it seems that at
least the NFS implementations I have run into have that much state.


So what am I missing?

	Peter Moore
	peter@objy.com