Subject: [nfsv4] RFC 7530: Locking clarification

From: Marcel Telka <[email-masked]>
Date: Mon, 14 Sep 2015 21:45:17 +0200

The section 16.10.5. in RFC 7530 reads:

   If the server is unable to determine the exact offset and length of
   the conflicting lock, the same offset and length that were provided
   in the arguments should be returned in the denied results.  Section 9
   contains a full description of this and the other file locking
   operations.

What in a case the server is unable to determine either the owner and/or the
type of the conflicting lock?

Thank you.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   [email-masked]  |
|                homepage: http://telka.sk/ |
|                jabber:   [email-masked] |
+-------------------------------------------+

---

From: Marcel Telka <[email-masked]>
Date: Tue, 29 Sep 2015 00:16:45 +0200

> type of the conflicting lock?

Anyone would be able to help me with this?

... I'm asking because in 16.10.4. it is stated the following (considering the
errata):

   In the case that the lock is denied, the owner, offset, length, and
   type of a conflicting lock are returned.

This assumes that the server should determine the owner, offset, length, and
type of the conflicting lock.  If the server is unable to determine the offset
and length, the 16.10.5. suggests to return the same offset and length as
provided in the arguments.  That's okay.

What in a case the server have a hard time to determine anything about the
conflicting lock?  Assume the server tried to get the lock (on the LOCK
operation), but failed because there is a conflicting lock.  The server tried
to find what is the conflicting lock (the owner, offset, length, and type), but
failed (for some reason) to determine anything about the conflicting lock.
What should the server return in this case?  Should it fabricate some random
owner and type (the offset and length will be same as in the arguments).  Or,
should it just return the same owner and type as provided in the arguments?  Or
anything else?

Thanks.

---

From: "Frank Filz" <[email-masked]>
Date: Tue, 29 Sep 2015 11:47:51 -0700

> > What in a case the server is unable to determine either the owner
> > and/or the type of the conflicting lock?
> 
> This assumes that the server should determine the owner, offset, length,
> and type of the conflicting lock.  If the server is unable to determine
the
> offset and length, the 16.10.5. suggests to return the same offset and
length
> as provided in the arguments.  That's okay.
> 
> operation), but failed because there is a conflicting lock.  The server
tried to
> find what is the conflicting lock (the owner, offset, length, and type),
but
> should it just return the same owner and type as provided in the
arguments?
> Or anything else?

I think it should fabricate an owner and type.

If the requested lock is shared, the conflicting type MUST be exclusive, so
it may be easiest to just always assume conflicting type is exclusive.

I'm curious if any application actually depends on getting accurate
information on the conflicting lock. I can see a test suite using the
conflicting lock information to try and verify correctness of operation
(especially after splitting or combining locks).

Note also that there could be multiple conflicting locks and the server will
just pick one such lock (presumably the first conflicting lock it comes
across in it's processing of the lock request).

Frank

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: David Noveck <[email-masked]>
Date: Tue, 29 Sep 2015 15:40:50 -0400

> I think it should fabricate an owner and type..

since the protocol doesn't allow you to tell the truth
(i.e, there is no "I don;t know"), you have to lie.  However, if you
have t lie, you should take care not to be (easily) caught.

> so it may be easiest to just always assume conflicting type is
> exclusive.

That makes sense.

With regard to the owner, the thing to make sure of is not to return
the current owner, since such a situation should not result in a conflict.

It is also troublesome to return the current clientid since the client is
in
a position to know what fabricated owner id strings are valid.  I'd suggest
using
a clientid different from any existing clientid on the server.

On Tue, Sep 29, 2015 at 2:47 PM, Frank Filz <[email-masked]> wrote:

> > ... I'm asking because in 16.10.4. it is stated the following
> (considering
> the
> > errata):
> >
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "Frank Filz" <[email-masked]>
Date: Tue, 29 Sep 2015 13:23:55 -0700

> since the protocol doesn't allow you to tell the truth (i.e, there is no "I don;t
> know"), you have to lie.  However, if you have t lie, you should take care not
> to be (easily) caught.

True.

> With regard to the owner, the thing to make sure of is not to return the
> current owner, since such a situation should not result in a conflict.
> 
> It is also troublesome to return the current clientid since the client is in a
> position to know what fabricated owner id strings are valid.  I'd suggest using

Ganesha returns a clientid of 0 (which will never be a real clientid4 value) and the owner opaque set to the string "ganesha_unknown_owner" which is exceedingly unlikely to ever be a real owner.

Frank

> > This assumes that the server should determine the owner, offset,
> > length, and type of the conflicting lock.  If the server is unable to
> > determine
> the
> > What in a case the server have a hard time to determine anything about
> > the conflicting lock?  Assume the server tried to get the lock (on the
> > LOCK operation), but failed because there is a conflicting lock.  The
> > server
> tried to
> If the requested lock is shared, the conflicting type MUST be exclusive, so it
> may be easiest to just always assume conflicting type is exclusive.
> 
> information on the conflicting lock. I can see a test suite using the conflicting
> lock information to try and verify correctness of operation (especially after
> splitting or combining locks).
> 
> Note also that there could be multiple conflicting locks and the server will just
> pick one such lock (presumably the first conflicting lock it comes across in it's
> processing of the lock request).
> 
> Frank
> 
> 
> ---

---