LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

fcntl.2: nfsv4leasetime controls the "contact lost" interval for NFSv4 

Jeff Layton:
   The difference here is subtle. The gracetime is how long after a reboot
   should knfsd allow clients to reclaim state (and deny the creation of
   new locks and opens). The leasetime is how long the NFSv4 lease period
   is. There is a relationship between the two that's illustrated in the
   comments above write_gracetime:

     /**
      * write_gracetime - Set or report current NFSv4 grace period time
      *
      * As above, but sets the time of the NFSv4 grace period.
      *
      * Note this should never be set to less than the *previous*
      * lease-period time, but we don't try to enforce this.  (In the common
      * case (a new boot), we don't know what the previous lease time was
      * anyway.)
      */

   The value you're interested in here is the nfsv4leasetime. If the
   client doesn't renew its lease within that period, then it's subject to
   the server giving up on it and dropping any state that it holds on that
   clients' behalf.

   Note that this is not a firm timeout. The server runs a job
   periodically to clean out expired stateful objects, and it's likely
   that there is some time (maybe even up to another whole lease period)
   between when the timeout expires and the job actually runs. If the
   client gets a RENEW in there within that window, its lease will be
   renewed and its state preserved.

Reported-by: Jeff Layton <jlayton@poochiereds.net>
Cowritten-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-04-29 12:00:44 +02:00
parent af8713605a
commit da0d60febb
1 changed files with 15 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
man2/fcntl.2
View File

@ -1278,16 +1278,27 @@ may live on a different machine.
Before Linux 3.12, if an NFSv4 client
loses contact with the server for a period of time
(defined as more than 90 seconds with no communication),
.\" FIXME: The 90 seconds is either /proc/fs/nfsd/nfsv4leasetime or
.\" /proc/fs/nfsd/nfsv4gracetime. Which is it? My suspicion, looking at
.\" fs/lockd/svcproc.c and fs/lockd/grace.c::locks_in_grace() is that
.\" it is /proc/fs/nfsd/nfsv4gracetime that is relevant here.
.\"
.\" Neil Brown: With NFSv3 the failure mode is the reverse. If
.\" the server loses contact with a client then any lock stays in place
.\" indefinitely ("why can't I read my mail"... I remember it well).
.\"
it might lose and regain a lock without ever being aware of the fact.
(The period of time after which contact is assumed lost is known as
the NFSv4 leasetime.
On a Linux NFS server, this can be determined by looking at
.IR /proc/fs/nfsd/nfsv4leasetime ,
which expresses the period in seconds.
The default value for this file is 90.)
.\"
.\" Jeff Layton:
.\" Note that this is not a firm timeout. The server runs a job
.\" periodically to clean out expired stateful objects, and it's likely
.\" that there is some time (maybe even up to another whole lease period)
.\" between when the timeout expires and the job actually runs. If the
.\" client gets a RENEW in there within that window, its lease will be
.\" renewed and its state preserved.
.\"
This scenario potentially risks data corruption,
since another process might acquire a lock in the intervening period
and perform file I/O.