Skip to content
  1. Sep 27, 2014
  3. Sep 18, 2014
    • J. Bruce Fields's avatar
      nfsd4: clarify how grace period ends · 70b28235
      J. Bruce Fields authored 
      

The grace period is ended in two steps--first userland is notified that
the grace period is now long enough that any clients who have not yet
reclaimed can be safely forgotten, then we flip the switch that forbids
reclaims and allows new opens.  I had to think a bit to convince myself
that the ordering was right here.  Document it.

Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      70b28235
    • J. Bruce Fields's avatar
      nfsd4: stop grace_time update at end of grace period · bea57fe4
      J. Bruce Fields authored 
      

The attempt to automatically set a new grace period time at the end of
the grace period isn't really helpful.  We'll probably shut down and
reboot before we actually make use of the new grace period time anyway.
So may as well leave it up to the init system to get this right.

This just confuses people when they see /proc/fs/nfsd/nfsv4gracetime
change from what they set it to.

Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      bea57fe4
    • Jeff Layton's avatar
      nfsd: skip subsequent UMH "create" operations after the first one for v4.0 clients · 65decb65
      Jeff Layton authored 
      

In the case of v4.0 clients, we may call into the "create" client
tracking operation multiple times (once for each openowner). Upcalling
for each one of those is wasteful and slow however. We can skip doing
further "create" operations after the first one if we know that one has
already been done.

v4.1+ clients generally only call into this function once (on
RECLAIM_COMPLETE), and we can't skip upcalling on the create even if the
STABLE bit is set. Doing so would make it impossible for nfsdcltrack to
lift the grace period early since the timestamp has a different meaning
in the case where the client is expected to issue a RECLAIM_COMPLETE.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      65decb65
    • Jeff Layton's avatar
      nfsd: set and test NFSD4_CLIENT_STABLE bit to reduce nfsdcltrack upcalls · 788a7914
      Jeff Layton authored 
      

The nfsdcltrack upcall doesn't utilize the NFSD4_CLIENT_STABLE flag,
which basically results in an upcall every time we call into the client
tracking ops.

Change it to set this bit on a successful "check" or "create" request,
and clear it on a "remove" request.  Also, check to see if that bit is
set before upcalling on a "check" or "remove" request, and skip
upcalling appropriately, depending on its state.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      788a7914
    • Jeff Layton's avatar
      nfsd: serialize nfsdcltrack upcalls for a particular client · d682e750
      Jeff Layton authored 
      

In a later patch, we want to add a flag that will allow us to reduce the
need for upcalls. In order to handle that correctly, we'll need to
ensure that racing upcalls for the same client can't occur. In practice
it should be rare for this to occur with a well-behaved client, but it
is possible.

Convert one of the bits in the cl_flags field to be an upcall bitlock,
and use it to ensure that upcalls for the same client are serialized.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d682e750
    • Jeff Layton's avatar
      nfsd: pass extra info in env vars to upcalls to allow for early grace period end · d4318acd
      Jeff Layton authored 
      

In order to support lifting the grace period early, we must tell
nfsdcltrack what sort of client the "create" upcall is for. We can't
reliably tell if a v4.0 client has completed reclaiming, so we can only
lift the grace period once all the v4.1+ clients have issued a
RECLAIM_COMPLETE and if there are no v4.0 clients.

Also, in order to lift the grace period, we have to tell userland when
the grace period started so that it can tell whether a RECLAIM_COMPLETE
has been issued for each client since then.

Since this is all optional info, we pass it along in environment
variables to the "init" and "create" upcalls. By doing this, we don't
need to revise the upcall format. The UMH upcall can simply make use of
this info if it happens to be present. If it's not then it can just
avoid lifting the grace period early.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d4318acd
    • Jeff Layton's avatar
      nfsd: add a v4_end_grace file to /proc/fs/nfsd · 7f5ef2e9
      Jeff Layton authored 
      

Allow a privileged userland process to end the v4 grace period early.
Writing "Y", "y", or "1" to the file will cause the v4 grace period to
be lifted.  The basic idea with this will be to allow the userland
client tracking program to lift the grace period once it knows that no
more clients will be reclaiming state.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      7f5ef2e9
    • Jeff Layton's avatar
      lockd: add a /proc/fs/lockd/nlm_end_grace file · d68e3c4a
      Jeff Layton authored 
      

Add a new procfile that will allow a (privileged) userland process to
end the NLM grace period early. The basic idea here will be to have
sm-notify write to this file, if it sent out no NOTIFY requests when
it runs. In that situation, we can generally expect that there will be
no reclaim requests so the grace period can be lifted early.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d68e3c4a
    • Jeff Layton's avatar
      nfsd: reject reclaim request when client has already sent RECLAIM_COMPLETE · 3b3e7b72
      Jeff Layton authored 
      

As stated in RFC 5661, section 18.51.3:

    Once a RECLAIM_COMPLETE is done, there can be no further reclaim
    operations for locks whose scope is defined as having completed
    recovery.  Once the client sends RECLAIM_COMPLETE, the server will
    not allow the client to do subsequent reclaims of locking state for
    that scope and, if these are attempted, will return
    NFS4ERR_NO_GRACE.

Ensure that we enforce that requirement.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      3b3e7b72
    • Jeff Layton's avatar
      nfsd: remove redundant boot_time parm from grace_done client tracking op · 919b8049
      Jeff Layton authored 
      

Since it's stored in nfsd_net, we don't need to pass it in separately.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      919b8049
    • Jeff Layton's avatar
      lockd: move lockd's grace period handling into its own module · f7790029
      Jeff Layton authored 
      

Currently, all of the grace period handling is part of lockd. Eventually
though we'd like to be able to build v4-only servers, at which point
we'll need to put all of this elsewhere.

Move the code itself into fs/nfs_common and have it build a grace.ko
module. Then, rejigger the Kconfig options so that both nfsd and lockd
enable it automatically.

Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      f7790029
  5. Sep 11, 2014
  7. Sep 04, 2014
  9. Sep 03, 2014
  11. Aug 29, 2014
  13. Aug 19, 2014
    • Rajesh Ghanekar's avatar
      nfsd: allow turning off nfsv3 readdir_plus · 18c01ab3
      Rajesh Ghanekar authored 
      

One of our customer's application only needs file names, not file
attributes. With directories having 10K+ inodes (assuming buffer cache
has directory blocks cached having file names, but inode cache is
limited and hence need eviction of older cached inodes), older inodes
are evicted periodically. So if they keep on doing readdir(2) from NSF
client on multiple directories, some directory's files are periodically
removed from inode cache and hence new readdir(2) on same directory
requires disk access to bring back inodes again to inode cache.

As READDIRPLUS request fetches attributes also, doing getattr on each
file on server, it causes unnecessary disk accesses. If READDIRPLUS on
NFS client is returned with -ENOTSUPP, NFS client uses READDIR request
which just gets the names of the files in a directory, not attributes,
hence avoiding disk accesses on server.

There's already a corresponding client-side mount option, but an export
option reduces the need for configuration across multiple clients.

This flag affects NFSv3 only.  If it turns out it's needed for NFSv4 as
well then we may have to figure out how to extend the behavior to NFSv4,
but it's not currently obvious how to do that.

Signed-off-by: default avatarRajesh Ghanekar <rajesh_ghanekar@symantec.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      18c01ab3
  15. Aug 18, 2014