: The RFC for NFS version 2 (http://tools.ietf.org/html/rfc1094) says: "All
: of the procedures in the NFS protocol are assumed to be synchronous. When
: a procedure returns to the client, the client can assume that the operation
: has completed and any data associated with the request is now on stable
: storage."
the key there being the words "stable storage" -- a guarantee that all
modifications have made it to stable storage when the operation returns is
not the same as a guarantee that other clients will "see" those changes in
the same order. Unless I'm mistaken you could write the segments file,
and then delete the lock file and another client asking for the lock file
will see that one isn't there, but when they ask for hte segments file may
get the *old* file from a local cache
: So if writer did actions { a1 , a2 } in this order and they completed, it
: seems that a reader "seeing" the result of action a2 must also "feel" the
: result of action a1. (This would prevent errors with the proposed version
: number.) But I am no expert in NFS and may be wrong here.
I think that because of NFS caching thats only true when a1 and
a2 deal with the same file -- i could be wrong however. If i'm right then
your proposal suffers the same problem (another client might see all of
the changes you've made to the version file and think the index is in a
consistent state, but not realize that the file is a stale cached file.
I'm not saying your proposal is bad -- just that i don't think it will
solve all the problems you think it will solve.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
