Subject: RE: LOCK_RANGE questions

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 Aug 2002 08:32:25 -0700

> > Section 14.2.11 (LOCKT) says "LOCKT will not return
> > NFS4ERR_LOCK_RANGE."  That sounds unnecessarily restrictive on the
> > server.  If possible, please change "will not" to "need not".

> It seems reasonable that the LOCKT operation should be symmetric to
> LOCK.  Maybe Dave Noveck can offer an opinion here since he supplied
> the text for these updates.

I don't see these as very similar at the implementation level.  If
you haven't drunk the POSIX locking cool-aid, then you simply cannot
implement POSIX-locking LOCK, while LOCKT is pretty easy.  So I 
don't see that it's so good to force the client to emulate this
by doing LOCKT on each of the regions that he does have locks and
all of the gaps between those regions, within the area that he
wants to LOCKT.  Also, if you want to allow LOCKT of an upgrade
of a region that you hold (or a subrange), things can get nightmarish
for the client.  If a non-POSIX locking environment, I think you
would have to do unlock and then lockt (does NT allow upgrade of
byte-range locks?).  It is true that you would have to do this
for a LOCK upgrade, raising atomicity issues, but it seems a lot
worse to require this on what is ostensibly a passive query.

I'm OK with "need not", though.  In actual fact, the number of 
people who require POSIX locking semantics is very small and
they would use a server that supports POSIX locking.  When I say
"very small", there is no necessary implication that the number
is different from zero :-)

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 Aug 2002 20:13:32 -0700

Fine with me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 09, 2002 7:23 PM
To: Noveck, Dave
Cc: [email-masked]'; [email-masked]
Subject: Re: LOCK_RANGE questions 

How about

    ...the server will return the error NFS4ERR_LOCK_RANGE.  In that
    case, the client may return an error, or it may emulate the
    required operations, using only LOCK for ranges that do not
    include any bytes already locked by that lockowner and LOCKU of
    locks held by that lockowner (specifying an exactly-matching range
    and type). Similarly, ...

?

mike