Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 06 7月, 2016 1 次提交
  3. 26 5月, 2016 1 次提交
  5. 18 5月, 2016 4 次提交
    • J
      pnfs: rework LAYOUTGET retry handling · 183d9e7b
      由 Jeff Layton 提交于 
      There are several problems in the way a stateid is selected for a
LAYOUTGET operation:

We pick a stateid to use in the RPC prepare op, but that makes
it difficult to serialize LAYOUTGETs that use the open stateid. That
serialization is done in pnfs_update_layout, which occurs well before
the rpc_prepare operation.

Between those two events, the i_lock is dropped and reacquired.
pnfs_update_layout can find that the list has lsegs in it and not do any
serialization, but then later pnfs_choose_layoutget_stateid ends up
choosing the open stateid.

This patch changes the client to select the stateid to use in the
LAYOUTGET earlier, when we're searching for a usable layout segment.
This way we can do it all while holding the i_lock the first time, and
ensure that we serialize any LAYOUTGET call that uses a non-layout
stateid.

This also means a rework of how LAYOUTGET replies are handled, as we
must now get the latest stateid if we want to retransmit in response
to a retryable error.

Most of those errors boil down to the fact that the layout state has
changed in some fashion. Thus, what we really want to do is to re-search
for a layout when it fails with a retryable error, so that we can avoid
reissuing the RPC at all if possible.

While the LAYOUTGET RPC is async, the initiating thread always waits for
it to complete, so it's effectively synchronous anyway. Currently, when
we need to retry a LAYOUTGET because of an error, we drive that retry
via the rpc state machine.

This means that once the call has been submitted, it runs until it
completes. So, we must move the error handling for this RPC out of the
rpc_call_done operation and into the caller.

In order to handle errors like NFS4ERR_DELAY properly, we must also
pass a pointer to the sliding timeout, which is now moved to the stack
in pnfs_update_layout.

The complicating errors are -NFS4ERR_RECALLCONFLICT and
-NFS4ERR_LAYOUTTRYLATER, as those involve a timeout after which we give
up and return NULL back to the caller. So, there is some special
handling for those errors to ensure that the layers driving the retries
can handle that appropriately.
Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      183d9e7b
    • J
      pnfs: only tear down lsegs that precede seqid in LAYOUTRETURN args · 6d597e17
      由 Jeff Layton 提交于 
      LAYOUTRETURN is "special" in that servers and clients are expected to
work with old stateids. When the client sends a LAYOUTRETURN with an old
stateid in it then the server is expected to only tear down layout
segments that were present when that seqid was current. Ensure that the
client handles its accounting accordingly.
Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      6d597e17
    • J
      pnfs: keep track of the return sequence number in pnfs_layout_hdr · 3982a6a2
      由 Jeff Layton 提交于 
      When we want to selectively do a LAYOUTRETURN, we need to specify a
stateid that represents most recent layout acquisition that is to be
returned.

When we mark a layout stateid to be returned, we update the return
sequence number in the layout header with that value, if it's newer
than the existing one. Then, when we go to do a LAYOUTRETURN on
layout header put, we overwrite the seqid in the stateid with the
saved one, and then zero it out.
Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      3982a6a2
    • J
      pnfs: record sequence in pnfs_layout_segment when it's created · 66755283
      由 Jeff Layton 提交于 
      In later patches, we're going to teach the client to be more selective
about how it returns layouts. This means keeping a record of what the
stateid's seqid was at the time that the server handed out a layout
segment.
Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      66755283
  7. 09 5月, 2016 1 次提交
  9. 28 1月, 2016 1 次提交
  11. 05 1月, 2016 3 次提交
  13. 01 1月, 2016 1 次提交
  15. 29 12月, 2015 3 次提交
  17. 23 9月, 2015 1 次提交
  19. 26 8月, 2015 5 次提交
  21. 19 8月, 2015 1 次提交
    • T
      NFSv4.1/pnfs: Fix a close/delegreturn hang when return-on-close is set · 4ff376fe
      由 Trond Myklebust 提交于 
      The helper pnfs_roc() has already verified that we have no delegations,
and no further open files, hence no outstanding I/O and it has marked
all the return-on-close lsegs as being invalid.
Furthermore, it sets the NFS_LAYOUT_RETURN bit, thus serialising the
close/delegreturn with all future layoutget calls on this inode.

The checks in pnfs_roc_drain() for valid layout segments are therefore
redundant: those cannot exist until another layoutget completes.
The other check for whether or not NFS_LAYOUT_RETURN is set, actually
causes a hang, since we already know that we hold that flag.

To fix, we therefore strip out all the functionality in pnfs_roc_drain()
except the retrieval of the barrier state, and then rename the function
accordingly.
Reported-by: NChristoph Hellwig <hch@infradead.org>
Fixes: 5c4a79fb ("Don't prevent layoutgets when doing return-on-close")
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      4ff376fe
  23. 13 8月, 2015 1 次提交
  25. 27 6月, 2015 1 次提交
  27. 24 6月, 2015 1 次提交
  29. 16 4月, 2015 1 次提交
  31. 28 3月, 2015 4 次提交
  33. 18 2月, 2015 1 次提交
  35. 04 2月, 2015 9 次提交