Subject: RE: [nfsv4] Locking Sematics

From: Mike Eisler <[email-masked]>
Date: Tue, 15 Mar 2005 07:28:34 -0800

I interpreted Syam's question to be completely
about advisory byte range locks, and not Windows style
share reservations.

Thus, I think the question boils down to what
are read and write byte range locks (which RFC 3530
mostly refers to), and do they have the semantics of
shared and exclusive locks (which the RFC makes a
handful of references to). However, the RFC doesn't
clearly state that read locks are shared locks,
and write locks are exclusive locks, though one
can make such an inference from:

    A lock may not be granted while a READ or WRITE operation using one
    of the special stateids is being performed and the range of the lock
    request conflicts with the range of the READ or WRITE operation.  For
    the purposes of this paragraph, a conflict occurs when a shared lock
    is requested and a WRITE operation is being performed, or an
    exclusive lock is requested and either a READ or a WRITE operation is
    being performed.  A SETATTR that sets size is treated similarly to a
    WRITE as discussed above.

We (the authors of the RFC) assumed that
read locks are shared locks, and write
locks are exclusive locks, and further that
shared locks do not conflict with shared locks
but do conflict with exclusive locks. Exclusive
locks conflict with exclusive locks and shared locks.
Again, such an inference can be drawn from the above
passage. Given Syam's question, obviously we could have
been clearer.

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

---

From: "Halevy, Benny" <[email-masked]>
Date: Wed, 16 Mar 2005 07:00:56 -0500

> In general, for every given server, there are probably clients that
> depend on the exact server behavior towards locking. So I suppose my
> question should be something along the lines of "Would enforcing locks
> on WRITE only and not on READ result in client compatiblity issues?"

Of course.  The server must conform to the nfsv4 specification
otherwise major interoperability issues will arise.

I think that the semantics you described may be achieved for clients
who wish for them by using the special stateid of all bits 1 on read
operations.  See RFC3530 section 8.1.4 [Page 73]

   A stateid of all bits 1 (one) MAY allow READ operations to bypass
   locking checks at the server.

Benny

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Syam Pannala
> Sent: Wednesday, March 16, 2005 8:22 AM
> To: [email-masked]
> Subject: Re: [nfsv4] Locking Sematics
> 
> 
> hi,
> 
> Firstly, when I said "fail operation X", I meant "fail operation X in
> case it does not supply the appropriate stateid". I guess I 
> should have
> stated that also.
> 
> > A WRITE operation can only succeed if the stateid in that
> > operation is the result of a lock_owner having acquired
> > an exclusive record lock.
> > A READ operation can only succeed if the stateid in that
> > operation is the result of a lock_owner having acquired
> > an exclusive or a shared record lock.
> 
> Actually, these semantics are different from what I had in mind. My
> idea was to ignore locks on a READ and honor locks only a WRITE (i.e.
> fail the WRITE if it does not supply the correct stateid). The above
> model needs "at least" shared locks for read and an exclusive lock for
> a write. In my model, you can either take shared or exclusive locks,
> but they are enforced only against a WRITE operation. 
> Ofcourse, one can
> question the value of shared write locks, but the WebDAV protocol
> allows them (hence they are probably not completely useless).
> 
> Have said that, I am now wondering if my model will cause 
> problems with
> existing/new nfsv4 clients trying to connect to my server. Is it the
> general expection that byte range locks affect both the read and write
> operations? Are there well known/any client applications that 
> depend on
> other people's READ being locked out?
> 
> In general, for every given server, there are probably clients that
> depend on the exact server behavior towards locking. So I suppose my
> question should be something along the lines of "Would enforcing locks
> on WRITE only and not on READ result in client compatiblity issues?"
> 
> Thanks to everybody for the responses so far. Please let me 
> know if you
> need any clarification.
> 
> -- Syam
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Easier than ever with enhanced search. Learn more. 
> http://info.mail.yahoo.com/mail_250
>