Subject: Re: [nfsv4] Semantics of mandatory byte-range locking

From: [email-masked]
Date: Thu, 14 Sep 2006 12:08:43 -0400 (EDT)

> If client A has a file open for read which client B has open for write,
> then you are not in situation (1), which is forbidden in the
> close-to-open model.

My understanding of close-to-open consistency is:
If Client B opens a file AFTER Client A has closed it (co-ordinated via
something other than file I/O ops), then Client B should see the changes
made by Client A.

Nothing forbids concurrent Opens by multiple clients and there are no
guarantees w.r.t. coherency for that case, UNLESS locking is being used.
(I assumed that was your "2)" case.) Obviously Open/Share locks can be used to
prevent concurrent read/write sharing, as well, but I had assumed that clients
weren't using OPEN_SHARE_DENY.

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Sep 2006 13:22:38 -0400

> weren't using OPEN_SHARE_DENY.

Same difference. The caching model breaks down, and your applications
are up the creek without a paddle if they were expecting it to work.

If you are using locking, then you are in the case (2) cache consistency
model, but only if _both_ clients are using locking. That model too
breaks down if one client tries to access the file without using
locking.

   Trond