A new and very robust method for doing file locking over NFS?

[Jeff Epler]

The other problem you run into with NFS is that the client might see
stale data.

In old-fashioned NFS client/server setups, a client does an attribute
fetch to determine whether cached data (file contents) is still current.
Time stamps have 1-second granularity.  If you have an operation that
does not require very long to complete, a client can see out-of-date
information.  Example (lock/unlock correspond to calls to a custom lock
daemon over TCP, just as you suggest):
    Client 1        Client 2
    Lock file
    ---------------------
    Write something
    Unlock

    Lock file
    Read it
    Unlock
                    Lock file
                    Write something
    ---------------------
                    Unlock
    Lock file
    read it 

If the actions between the dashed lines all took place within the same
wall second, client 1 may read its own cached data instead of the data
written by client 2.  Our eventual solution was a kernel patch which let
us evict any cached data for a particular file from memory, and we did
it every time we performed a locking operation.  You can bet that
performance suffered, but at least it was correct.

I don't know if any of these problems have been corrected.  I think that
some NFS servers have timestamps that have finer resolution than one
second.

Jeff