Subject: RE: [nfsv4] CB_NOTIFY_LOCK

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 21 Aug 2006 16:59:42 -0400

I like the OPEN rflag.  One worry about doing something 
different once you wee CB_NOTIFY_LOCK is the possiblity of 
a server that does this only for some fs's leading to client 
confusion.  Since you have to have an open file to do the 
locking, an indication at open time, would seem to take care 
of all realistic worries (and maybe some unrealistic ones as 
well :-).

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 4:27 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] CB_NOTIFY_LOCK

On Mon, Aug 21, 2006 at 02:35:03PM -0400, Noveck, Dave wrote:
> I think it needs some sort of indication by the server that it does
> support this.  It doesn't have to be an absolute promise (so the 
> client does have to poll), but clients are going to want to poll
> at different frequencies for a server that does have this support
> vs. one that has no such support.

They could just default to their 4.0 policy until they actually see a
NOTIFY_LOCK callback, and then adjust accordingly.

It'd be trivial to add a single-bit server-wide "NOTIFY_LOCK support"
attribute (or even an additional bit for the OPEN rflags result, to give
the server the ability to hint differently depending on client,
filesystem, etc.?), but we might be getting to the point of diminishing
returns--all you'd be preventing would be slightly over-agressive
polling the first time a new client hit a contended lock.

--b.

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