Subject: [nfsv4] Mandatory

From: Stevan Steve Allen <[email-masked]>
Date: Wed, 21 Jan 2004 09:19:49 -0700

Which is the purpose/direction of mandatory byte range locking.. 

1.  Enables each platform to protect their unique proprietary kernel 
locking semantics.
2.  An approach  to define a common mandatory locking semantic across all 
platforms.

I suspect there are some network purist which dislikes the thought of 
providing item 1.  in an open system protocol.

Thanks,
Stevan C. Allen

The  best questions answer themselves. 
Wrong questions take longer.

---

From: David Robinson <[email-masked]>
Date: Wed, 21 Jan 2004 13:32:57 -0600

> providing item 1.  in an open system protocol.

Not sure which choice this is, but my recollection was that mandatory
locking was added because there were interesting platforms that
supported it (possibly only mandatory locking) and it was better
to specify the semantics than allow arbitrary behavior. The semantics
chosen were ones that appeared most flexible.

Two competing mandatory locking schemes are Windows and SYSV.  In the
former conflicting requests return back an error while in the
latter the request just blocks. Blocking seems bad as it will
tend to chew up resources and gets ugly in the face of
retransmits and recovery, but you can simulate blocking on the client if
the server returns an error.  Albeit with weaker fairness.

So I would say that it was specified to create well defined
semantics that would allow most known OS semantics to be
reasonably mapped.

The server semantics are pretty minimally defined from the
perspective of the network but undefined with respect
to local accesses. The client can choose to react to replies
as it feels necessary including such anti-social behavior
as rapidly polling.

If there is a semantic that cannot be reasonably mapped there
is potential that it could be defined in a minor release,
possibly as a new attribute that allows the server to tell
the client how it will behave.

	-David

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