Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 7月, 2017 1 次提交
    • C
      NFSv4.1: Handle EXCHGID4_FLAG_CONFIRMED_R during NFSv4.1 migration · 8dcbec6d
      由 Chuck Lever 提交于 
      Transparent State Migration copies a client's lease state from the
server where a filesystem used to reside to the server where it now
resides. When an NFSv4.1 client first contacts that destination
server, it uses EXCHANGE_ID to detect trunking relationships.

The lease that was copied there is returned to that client, but the
destination server sets EXCHGID4_FLAG_CONFIRMED_R when replying to
the client. This is because the lease was confirmed on the source
server (before it was copied).

Normally, when CONFIRMED_R is set, a client purges the lease and
creates a new one. However, that throws away the entire benefit of
Transparent State Migration.

Therefore, the client must not purge that lease when it is possible
that Transparent State Migration has occurred.
Reported-by: NXuan Qi <xuan.qi@oracle.com>
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Tested-by: NXuan Qi <xuan.qi@oracle.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      8dcbec6d
  3. 21 4月, 2017 2 次提交
  5. 23 9月, 2016 1 次提交
    • J
      nfs: allow blocking locks to be awoken by lock callbacks · a1d617d8
      由 Jeff Layton 提交于 
      Add a waitqueue head to the client structure. Have clients set a wait
on that queue prior to requesting a lock from the server. If the lock
is blocked, then we can use that to wait for wakeups.

Note that we do need to do this "manually" since we need to set the
wait on the waitqueue prior to requesting the lock, but requesting a
lock can involve activities that can block.

However, only do that for NFSv4.1 locks, either by compiling out
all of the waitqueue handling when CONFIG_NFS_V4_1 is disabled, or
skipping all of it at runtime if we're dealing with v4.0, or v4.1
servers that don't send lock callbacks.

Note too that even when we expect to get a lock callback, RFC5661
section 20.11.4 is pretty clear that we still need to poll for them,
so we do still sleep on a timeout. We do however always poll at the
longest interval in that case.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
[Anna: nfs4_retry_setlk() "status" should default to -ERESTARTSYS]
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a1d617d8
  7. 18 5月, 2016 1 次提交
  9. 28 12月, 2015 1 次提交
  11. 16 10月, 2015 2 次提交
  13. 28 8月, 2015 1 次提交
  15. 23 7月, 2015 1 次提交
  17. 27 6月, 2015 1 次提交
  19. 04 2月, 2015 1 次提交
  21. 06 1月, 2015 1 次提交
  23. 26 11月, 2014 2 次提交
  25. 01 10月, 2014 1 次提交
  27. 13 7月, 2014 1 次提交
  29. 29 10月, 2013 3 次提交
  31. 02 10月, 2013 1 次提交
  33. 07 9月, 2013 1 次提交
    • A
      NFSv4.1 Use MDS auth flavor for data server connection · 0e20162e
      由 Andy Adamson 提交于 
      Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
uses the nfs_client cl_rpcclient for all state management operations, and
will use krb5i or auth_sys with no regard to the mount command authflavor
choice.

The MDS, as any NFSv4.1 mount point, uses the nfs_server rpc client for all
non-state management operations with a different nfs_server for each fsid
encountered traversing the mount point, each with a potentially different
auth flavor.

pNFS data servers are not mounted in the normal sense as there is no associated
nfs_server structure. Data servers can also export multiple fsids, each with
a potentially different auth flavor.

Data servers need to use the same authflavor as the MDS server rpc client for
non-state management operations. Populate a list of rpc clients with the MDS
server rpc client auth flavor for the DS to use.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0e20162e
  35. 05 9月, 2013 5 次提交
  37. 04 9月, 2013 1 次提交
  39. 09 6月, 2013 3 次提交
  41. 15 4月, 2013 1 次提交
  43. 26 3月, 2013 2 次提交
  45. 06 12月, 2012 5 次提交
  47. 27 11月, 2012 1 次提交