Subject: RE: [nfsv4] Mandatory

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 21 Jan 2004 15:10:20 -0800

Note that the spec (in section 5.11.5) says:

   Note that in UNIX, if a file has the MODE4_SGID bit set and no
   MODE4_XGRP bit set, then READ and WRITE must use mandatory file
   locking.

As others have pointed out, the spec has decided not to tell you 
what semantics to implement, but it seems to me that it is saying
that if you made that particular choice, you might have some company
(and that's a good thing).

David Robinson wrote:
> 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.

In the IMPLEMENTATION section of 14.3.36 (WRITE), the spec says:

   If mandatory file locking is on for the file, and corresponding
   record of the data to be written file is read or write locked by an
   owner that is not associated with the stateid, the server will return
   NFS4ERR_LOCKED. 

It doesn't say explicitly but I would argue that waiting for a relatively
short time before giving the error (for the lock to go away) is allowed
server behavior.

   If so, the client must check if the owner
   corresponding to the stateid used with the WRITE operation has a
   conflicting read lock that overlaps with the region that was to be
   written. If the stateid's owner has no conflicting read lock, then
   the client should try to get the appropriate write record lock via
   the LOCK operation before re-attempting the WRITE. When the WRITE
   completes, the client should release the record lock via LOCKU.

I assume that client can do the LOCK-WRITE-LOCKU in a compound and 
that the client can use WRITEW_LT so that section 8.4 becomes
applicable.

-----Original Message-----
From: David Robinson [mailto:[email-masked]]
Sent: Wednesday, January 21, 2004 2:33 PM
To: Stevan Steve Allen
Cc: [email-masked]
Subject: Re: [nfsv4] Mandatory

Stevan Steve Allen wrote:
> 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.

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

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 21 Jan 2004 17:34:23 -0600

> that the client can use WRITEW_LT so that section 8.4 becomes

But the client can not form a COMPOUND as you suggest since
the WRITE and LOCKU operations will not be able to obtain the
stateid returned from the LOCK operation.

Spencer

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 21 Jan 2004 18:33:21 -0500

> that the client can use WRITEW_LT so that section 8.4 becomes

You mean do LOCK-WRITE-LOCKU in a single compound? There is no method
for passing the new stateid generated by LOCK as an argument to either
the WRITE or the LOCKU.

What we need is the notion of a "current stateid" in the same way that
we have a "current filehandle". We've talked about this previously as
being a useful extension for 4.1, but there has been no attempt yet to
actually define the semantics for such a beast.

Cheers,
  Trond