On Thu, 2 Nov 2006, Andrew Laurence wrote:
NFSv4 is stateful, or claims to be. The take-away I got was that v4 is a
new, different beast; thus the initial question.
http://www.ietf.org/rfc/rfc3530.txt
I skimmed through RFC 3530. I see nothing that guarantees data
synchronization across multiple entities that have the file open.
Doing so requires that when a file is opened with write access, all other
opens of the file (whether read-only or read-write) are required to pass
around a token ensuring that no write has occurred to any data which is
currently cached for read. The moment a write occurs, the token has to be
invalidated and all opens that have cached data must purge their cache.
Apparently, RFC 3530 assumes that fcntl() locking range locks will
accomplish the necessary token pass/cache purge. Even if that worked,
that would require an fcntl() lock/release around every read() and
write(), and conflicts with the statement on page 65:
It is assumed that manipulating a lock is rare when compared to READ
and WRITE operations.
UW imapd does not lock records. Its lock is for the file, and it assumes
(as happens on any local filesystem) that any write() updates any buffer
cache used by a subsequent read().
We could try doing a lock record on every read()/write(). However, we
have to consider that, when the test-for-NFS was broken, UW imapd's
relatively locking managed to cause cluster-wide NFS hangs in the current
release of Solaris. It isn't difficult to speculate what a vast (orders
of magnitude) increase in locking would do.
Put another way, the experiment would require a great deal of technical
work (there's quite a bit that would have to change), and I expect that
the outcome would be a miserable failure.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
