Re: Non-blocking lock requests during the grace period

Re: Non-blocking lock requests during the grace period

[Juan Gomez]

On second thoughts, I think I wonder if we want to fail F_GETLK while in
the grace period? seems like we won't there it makes sense to hold until
the grace period clears otherwise the client app may think there is
something wrong (note that F_GETLK man page does not provide EAGAIN as
a possible error code).
The case for F_SETLK is different as the result is expected when the lock
is not available due to a previous holder (or, as I want to do it, when the
lock is not available ether by previous holder or grace period).


Juan



|---------+---------------------------->
|         |           Trond Myklebust  |
|         |           <trond.myklebust@|
|         |           fys.uio.no>      |
|         |                            |
|         |           11/15/02 09:35 AM|
|         |           Please respond to|
|         |           trond.myklebust  |
|         |                            |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                         |
  |       To:       Juan Gomez/Almaden/IBM@IBMUS                                                                            |
  |       cc:       linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net                                                 |
  |       Subject:  Re: Non-blocking lock requests during the grace period                                                  |
  |                                                                                                                         |
  |                                                                                                                         |
  >-------------------------------------------------------------------------------------------------------------------------|




     > 2.-I also have this part enclosed in the if(resp->status ==
     > NLM_LCK_DENIED_GRACE_PERIOD) as follows:

     > if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {

     >       blah blah...

     > wait_on_grace:
     >                          if ((proc == NLMPROC_LOCK) &&
     >                          !argp->block)
     >                                      return -EAGAIN
     > } else {

     >       ....
     > }

     > This with the intention to be very specific as to when we want
     > the return -EAGAIN to be called.

The above means that you will still block on a F_GETLK query...

In any case, why would we want to return -EAGAIN in one case where
argp->block isn't set, and not in another? If there are cases where we
want to block and where we are not currently setting argp->block (the
only one I can think of might be NLMPROC_UNLOCK), then we should fix
the caller.

Cheers,
  Trond

Re: Non-blocking lock requests during the grace period

[Trond Myklebust]

>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:

     > (note that F_GETLK man page does not provide EAGAIN as a
     > possible error code).

Hmm....

In the Single UNIX spec, there appears to be a rather unexpected
difference between expected behaviour for lockf and fcntl here:


http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=lockf

[EACCES] or [EAGAIN]
       The function argument is F_TLOCK or F_TEST and the section is already
       locked by another process.

OTOH

http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=fcntl

[EACCES] or [EAGAIN]
    The cmd argument is F_SETLK, and one of the following conditions
    is true:

        * The type of lock (l_type) is shared ( F_RDLCK) or exclusive
          ( F_WRLCK), and the segment of a file to be locked is
          already exclusive locked by another process.
        * The type of lock is exclusive, and some portion of the file
          segment to be locked is already shared locked or exclusive
          locked by another process.

Cheers,
  Trond

Re: [NFS] Re: Non-blocking lock requests during the grace period

[mike.kupfer]

>>>>> "Trond" == Trond Myklebust <trond.myklebust@fys.uio.no> writes:

>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:

    >> (note that F_GETLK man page does not provide EAGAIN as a
    >> possible error code).

F_GETLK indicates a conflict by changing the arg struct to show the
conflicting lock.

As for the original topic, I would hesitate before changing the client
locking code to return EAGAIN just because the server is in its grace
period.  The "blocking" or "non-blocking" behavior is tied to what
happens when there is already a lock that conflicts with the requested
one.  When the server is in the grace period, it's unknown as to
whether there is already a lock that conflicts with the requested
one.

Mike Kupfer				mike.kupfer@sun.com
Solaris File Sharing			Speaking for myself, not for Sun.

Re: [NFS] Re: Non-blocking lock requests during the grace period

[Juan Gomez]

Mike,

I agree with the F_GETLK part, as I pointed out to Trond earlier. However,
I feel it is odd to block a client for about one minutre when it issues
"non-blocking" lock requests. I have seen that Solaris code does so but
still feels odd and it may conflict with what most programmers expect,
though I see your point, perhaps if this was well documented in man pages
there would not be a problem. In Linux this is not the case.


Juan





|---------+---------------------------->
|         |           mike.kupfer@sun.c|
|         |           om               |
|         |           Sent by:         |
|         |           kupfer@athyra.eng|
|         |           .sun.com         |
|         |                            |
|         |                            |
|         |           11/18/02 05:04 PM|
|         |                            |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                         |
  |       To:       trond.myklebust@fys.uio.no                                                                              |
  |       cc:       Juan Gomez/Almaden/IBM@IBMUS, linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net                   |
  |       Subject:  Re: [NFS] Re: Non-blocking lock requests during the grace period                                        |
  |                                                                                                                         |
  |                                                                                                                         |
  >-------------------------------------------------------------------------------------------------------------------------|



>>>>> "Trond" == Trond Myklebust <trond.myklebust@fys.uio.no> writes:

>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:

    >> (note that F_GETLK man page does not provide EAGAIN as a
    >> possible error code).

F_GETLK indicates a conflict by changing the arg struct to show the
conflicting lock.

As for the original topic, I would hesitate before changing the client
locking code to return EAGAIN just because the server is in its grace
period.  The "blocking" or "non-blocking" behavior is tied to what
happens when there is already a lock that conflicts with the requested
one.  When the server is in the grace period, it's unknown as to
whether there is already a lock that conflicts with the requested
one.

Mike Kupfer                                            mike.kupfer@sun.com
Solaris File Sharing                                   Speaking for myself,
not for Sun.

Re: [NFS] Re: Non-blocking lock requests during the grace period

[Mike Kupfer]

>>>>> "Juan" == Juan Gomez <juang@us.ibm.com> writes:

    Juan> However, I feel it is odd to block a client for about one
    Juan> minutre when it issues "non-blocking" lock requests.

But if the server goes down, the call can end up blocking for
significantly longer than one minute anyway.

    Juan> I have seen that Solaris code does so but still feels odd
    Juan> and it may conflict with what most programmers expect

Perhaps, but there are other expectations to keep in mind.  In
particular, when using NFS, the expectation (at least with hard
mounts) is that when the server goes down, the application will simply
wait until the server comes back.  Your change would conflict with
that expectation.

Mike Kupfer				mike.kupfer@sun.com
Solaris File Sharing			Speaking for myself, not for Sun.