summaryrefslogtreecommitdiff
path: root/fs/ubifs/tnc_commit.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2017-06-08 11:52:52 -0400
committerAnna Schumaker <Anna.Schumaker@Netapp.com>2017-07-13 16:00:12 -0400
commit838edb94977b96f191800d7ce39b2505419aac4a (patch)
tree9abfbd6316c599430f91398bb681390f46afc986 /fs/ubifs/tnc_commit.c
parent8dcbec6d20eb881ba368d0aebc3a8a678aebb1da (diff)
NFSv4.1: Use seqid returned by EXCHANGE_ID after state migration
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). When CONFIRMED_R is set, the client throws away the sequence ID returned by the server. During a Transparent State Migration, however there's no other way for the client to know what sequence ID to use with a lease that's been migrated. Therefore, the client must save and use the contrived slot sequence value returned by the destination server even when CONFIRMED_R is set. Note that some servers always return a seqid of 1 after a migration. Reported-by: Xuan Qi <xuan.qi@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Xuan Qi <xuan.qi@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Diffstat (limited to 'fs/ubifs/tnc_commit.c')
0 files changed, 0 insertions, 0 deletions