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

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.

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.