Subject: RE: Lock upgrade semantics

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jan 2000 08:24:32 -0800

> Okay, I think this leaves us with what to say about UNIX clients and
> splitting locks.
> 
> I see the choices as
> 
>   1. if an application tries to split a lock, deny the request (e.g.,
>   return EINVAL).
> 
>   2. If an application tries to split a lock, emulate it by dropping
>   the original lock and creating 2 new locks, and hope that nothing
>   bad happens.
> 
>   3. If an application tries to split a lock, emulate it, but notify
>   the application if something went wrong.
> 
> I don't think choice 2 is acceptable.  It basically says that under
> certain edge conditions it's okay for user data to get silently
> corrupted.

I'm not sure that choice 3 is that much better.  In the situations
in which choice 2 will silently corrupt your data, choice 3 will
corrupt your data and tell you that it might have corrupted your
data.  It's nice to know, but you've still got corrupted file.   

If you adopt choice 3, you are allowing people to develop applications
that use this feature, deploy them using NFS-v4, and then find out, 
when load increases to a certain point, that they just won't work.
I think users would be upset at that.
  
> 
> If we can come up with a sufficiently strong way to detect that
> "something went wrong", I could go with either 1 or 3.  Otherwise, I
> think we should go with choice 1.  (And I'm afraid that so far I
> haven't come up with anything I'm happy with for detecting that
> something went wrong.)
> 
> Comments?
 
I think choice 1 is acceptable, mainly because there are so few uses
of this.  But I guess I'm sufficiently paranoid (or you've made me
sufficiently paranoid :-) to worry that there is someone developing 
an application that does this and that it's destined to be wildly 
popular.

So I'd like to offer choice 4:  Drop the statement about the byte
range of a lock being indivisible.  Allow a server which cannot 
support changes of a subrange (or an otherwise overlapping but
non-identical range) unlocked or changed, to return an error
(say NFS4ERR_LOCK_RANGE).  Right now, the spec implies that
all servers should give an error on this, but doesn't say 
which one.

Servers which can support this functionality would be allowed
to do so.  This would make this feature analogous to renaming
an open file.  Some servers will return an error and some 
won't.  The handling of such requests would be part of file
system semantics and not part of the protocol per se.  I
don't see that this would require any additional changes to
the protocol.  Am I missing something?

This divergence in possible server behavior would not add
complexity to clients.  The client would issue the lock/
unlock request and if it got an error, it would return an
error to the application.  If it worked, the application 
would have the support it needed.  A client would have to 
have a little bit more sophistication in its logic to keep 
track of what locks it had (for the reclaim logic) but it 
would need that only if it intended to take advantage of
this feature.  Clients which did not allow this at the
application level would be free to reject an operation 
on an overlapping but non-identical byte range without 
doing an RPC.

Since Unix clients cannot "simulate modifying subranges",
as draft-03 expects them to be able to do, it makes sense 
to allow them to use servers which support this on the 
server without requiring that all servers do so.

Comments?

---

From: Mike Kupfer <[email-masked]>
Date: Mon, 17 Jan 2000 10:40:17 -0800

> range of a lock being indivisible.

Sounds good to me.

> I

I can't think of any technical changes.

In terms of editorial changes, the only thing I can think of would be
to add some text about reclaims, to discourage clients from coalescing
adjacent regions into a single reclaim request.

mike