>>>>> " " == Chris Wedgwood <cw@f00f.org> writes:
>> With NFSv3 yes. v3 has some very nice ideas. One of these is
>> that write is a two phase operation. You do a write() you keep
>> the data cached locally and send it off to the server, later
>> you commit old data and the commit is allowed to fail forcing a
>> client resend of the write.
> So what happens if I store a token in a store via NFS -- I
> write(2) this token out, send a packet to something else which
> also has this store mounted, is reads it and sees the _old_
> data -- kaboom?
This problem of cache consistency is handled by use of the NLM file
locking protocol (i.e. POSIX locks) for both NFSv2 and NFSv3. Nothing
new here...
Clarification: There is nothing magical about NFSv3 caching. The only
new thing wrt NFSv2 is that the *server* can now safely cache data and
is not required to immediately flush it to disk. The client is only
allowed to assume that data has been physically flushed to disk once
the NFS3_COMMIT has been acknowledged by the server.
Please note that the knfsd server has consistently violated this part
of the NFSv2 protocol: knfsd acknowledges a write statement from the
client without ensuring that data has been flushed to disk, thus the
client is not guaranteed that anything it has written will survive a
server failure.
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:14 EST