Skip to content

L
linux
Switch branch/tag
  1. 29 Sep, 2014 3 commits
  3. 26 Sep, 2014 6 commits
  5. 17 Sep, 2014 11 commits
    • 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
  7. 11 Sep, 2014 1 commit
  9. 03 Sep, 2014 6 commits
  11. 02 Sep, 2014 2 commits
  13. 28 Aug, 2014 5 commits
  15. 18 Aug, 2014 1 commit
    • 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
  17. 17 Aug, 2014 5 commits
    • J. Bruce Fields's avatar
      nfsd4: reserve adequate space for LOCK op · f7b43d0c
      J. Bruce Fields authored 
      As of  8c7424cf "nfsd4: don't try to encode conflicting owner if low
on space", we permit the server to process a LOCK operation even if
there might not be space to return the conflicting lockowner, because
we've made returning the conflicting lockowner optional.

However, the rpc server still wants to know the most we might possibly
return, so we need to take into account the possible conflicting
lockowner in the svc_reserve_space() call here.

Symptoms were log messages like "RPC request reserved 88 but used 108".

Fixes: 8c7424cf "nfsd4: don't try to encode conflicting owner if low on space"
Reported-by: default avatarKinglong Mee <kinglongmee@gmail.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      f7b43d0c
    • J. Bruce Fields's avatar
      nfsd4: remove obsolete comment · 1383bf37
      J. Bruce Fields authored 
      We do what Neil suggests now.
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      1383bf37
    • Ross Lagerwall's avatar
      nfsd3: Check write permission after checking existence · 63bab065
      Ross Lagerwall authored 
      When creating a file that already exists in a read-only directory with
O_EXCL, the NFSv3 server returns EACCES rather than EEXIST (which local
files and the NFSv4 server return).  Fix this by checking the MAY_CREATE
permission only if the file does not exist.  Since this already happens
in do_nfsd_create, the check in nfsd3_proc_create can simply be removed.
Signed-off-by: default avatarRoss Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      63bab065
    • Jeff Layton's avatar
      nfsd: call nfs4_put_deleg_lease outside of state_lock · afbda402
      Jeff Layton authored 
      Currently, we hold the state_lock when releasing the lease. That's
potentially problematic in the future if we allow for setlease methods
that can sleep. Move the nfs4_put_deleg_lease call out of the delegation
unhashing routine (which was always a bit goofy anyway), and into the
unlocked sections of the callers of unhash_delegation_locked.
Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      afbda402
    • Jeff Layton's avatar
      nfsd: protect lease-related nfs4_file fields with fi_lock · 6bcc034e
      Jeff Layton authored 
      Currently these fields are protected with the state_lock, but that
doesn't really make a lot of sense. These fields are "private" to the
nfs4_file, and can be protected with the more granular fi_lock.

The fi_lock is already held when setting these fields. Make the code
hold the fp->fi_lock when clearing the lease-related fields in the
nfs4_file, and no longer require that the state_lock be held when
calling into this function.

To prevent lock inversion with the i_lock, we also move the vfs_setlease
and fput calls outside of the fi_lock. This also sets us up for allowing
vfs_setlease calls to block in the future.

Finally, remove a redundant NULL pointer check. unhash_delegation_locked
locks the fp->fi_lock prior to that check, so fp in that function must
never be NULL.
Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      6bcc034e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7