Subject: RE: [nfsv4] CB_NOTIFY_LOCK

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 22 Aug 2006 11:21:06 -0400

In the spirit of the dialog that Spencer suggests, yes, something like
CB_NOTIFY_LOCK seems to be a low-risk addition to NFSv4.1.  I'm in the
camp that would desire something like this, to help clients allow
applications to wait for locks without thrashing the network and the
server with lock polling.

		Craig

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Monday, August 21, 2006 7:28 PM
> To: [email-masked]
> Subject: Re: [nfsv4] CB_NOTIFY_LOCK
> 
> On Mon, J. Bruce Fields wrote:
> > On Mon, Aug 21, 2006 at 02:31:01PM -0500, Spencer Shepler wrote:
> > > Is highly coordinated file-locking a goal for NFS or 
> NFSv4.1 specifically.
> > 
> > I'm not sure what highly coordinated file-locking is.  I 
> think it'd be 
> > nice to support locking without requiring long delays to acquire 
> > contended locks, though, yes.
> 
> I meant "highly coordinated" to refer to a class of 
> applications where byte-range locks were in heavy use and 
> there is a reasonable probability that there will be 
> contention resulting in the kind of polling and delay to 
> which you refer.
> 
> 
> > > It has been my impression that application developers and 
> sys admins 
> > > have been sufficiently trained by the NFS locking ghosts 
> of the past 
> > > that NFS file locking is avoided at most if not all costs.
> > > Do we need to fix that now or do we believe that the application
> > 			     ^^
> > I'm assuming you mean "and" there.
> > 
> > > developer or sys admin will be sufficiently convinced that things 
> > > have changed that they can count on NFSv4.1 file locking support?
> > 
> > So far, we've:
> > 
> > 	- enabled local caching of locks using delegations,
> > 	- added support for windows share locks,
> > 	- added sequencing, etc., to fix locking races, and
> > 	- enabled mandatory locking by adding stateid's to 
> every read and
> > 	  write.
> > 
> > That suggests a certain level of interest both in making 
> life easier 
> > for existing users of locking and in expanding the sorts of locking 
> > users we can support.
> > 
> > Compared to that stuff, CB_NOTIFY_LOCK is trivial to 
> implement.  And 
> > it affects a core locking feature (advisory byte-range 
> locking) that 
> > people do seem to use.
> 
> Mike captured my intent; I am trying to have the dialog about 
> requirements given where we are with the development of 
> NFSv4.1.  Attempting to elicit the discussion around the 
> addition of new features: what is the impact of solving a 
> particular issue? is it required? nice to have?
> is is something that everyone "just wants", etc.
> 
> My apologies if the intent come across as I had hoped.
> 
> Spencer
> 
> 
> _______________________________________________
> 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: Tue, 22 Aug 2006 10:37:03 -0500

THanks for the input Craig.  I have created issue 111 to track the
resolution of this.

Spencer