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

From: [email-masked]
Date: Thu, 14 Sep 2006 11:33:59 -0400 (EDT)

> There are currently 3 caching models that NFS supports:
> 
>  1) Close to open cache consistency.
>  2) Byte range locked.
>  3) Uncached (i.e. O_DIRECT) reads/writes
> 
> For which of the above 3 cases are you and Mike arguing that we have a
> problem?

I'm thinking about 1). As I understand it, the following can happen:
- Client A reads bytes 0-1000 into a local cache successfully, from the server
- Client B puts write lock on bytes 0-1000
--> Now, if the server is implementing mandatory caching for that file,
    all reads of bytes 0-1000 should fail for Client A. But how does Client
    A know to disallow local Reads of those bytes from the cache? (If you
    don't implement that within the client, then what is the point of
    having mandatory caching?)

The problem is more serious for write caching. Again assuming 1).
- Client A writes bytes 0-1000 into a local cache and schedules write-back
  to the server.
- Client B puts a write lock on bytes 0-1000
--> Now, if the server is implementing mandatory locking, Client A's
    write-back fails with NFS4ERR_LOCKED.
  (Client A can avoid this by getting a write lock on bytes 0-1000 before
   allowing the write into the local cache. But, it either has to do this
   "all the time" OR know that the server is applying mandatory caching
   to that file. And, if mandatory caching can be switched on at any time?)

rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Sep 2006 11:36:10 -0400

>     having mandatory caching?)

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.

>    to that file. And, if mandatory caching can be switched on at any time?)

Again. The whole situation is forbidden by model (1).

Cheers,
  Trond

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 14 Sep 2006 11:44:56 -0400 (EDT)

--------

>> I'm thinking about 1)....

>then you are not in situation (1), which is forbidden in the

Forbidden?  I always figured it was permitted, but no promises were
in effect about consistency.  CTO is good for a client that writes a
file, closes it, and notifies another client to open the file and
read it.

>> The problem is more serious for write caching....

>Again. The whole situation is forbidden by model (1).

Run away!  Run away!  Or write an April Fools Day article titled
"Caching Considered Harmful."  I've never seen one, one of us
old fogies (or protege of Seymour Cray) should write it.

	-Ric Werme

---

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

> file, closes it, and notifies another client to open the file and

Close-to-open _assumes_ that the file will not be changed by some other
client while you have it open. If that is not the case, then you are
working outside of the close-to-open model.

> old fogies (or protege of Seymour Cray) should write it.

How about 'Mission critical applications for NFS in aircraft'?

  Trond

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 14 Sep 2006 12:01:12 -0400

Fly away!  Fly away!