From: Anna Schumaker <schumaker.anna@gmail.com>
To: Olga Kornievskaia <kolga@netapp.com>,
Trond.Myklebust@primarydata.com, anna.schumaker@netapp.com
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v8 00/13] NFS support for async intra COPY
Date: Fri, 20 Apr 2018 13:30:16 -0400 [thread overview]
Message-ID: <caa5e13f-ba11-e414-0f71-4c26d7572faa@gmail.com> (raw)
In-Reply-To: <20180413170314.17634-1-kolga@netapp.com>
Hi Olga,
On 04/13/2018 01:03 PM, Olga Kornievskaia wrote:
> Change the client side to always request an asynchronous copy.
>
> If server replies to the COPY with the copy stateid, client will go
> wait on the CB_OFFLOAD. To fend off the race between CB_OFFLOAD and
> COPY reply, we check the list of pending callbacks before going to
> wait. Client adds the copy to the global list of copy stateids for the
> callback to look thru and signal the waiting copy.
>
> When the client receives reply from the CB_OFFLOAD with some bytes and
> committed how is UNSTABLE, then COMMIT is sent to the server. The results
> are propagated to the VFS and application. Assuming that application
> will deal with a partial result and continue from the new offset if needed.
>
> If server errs with ERR_OFFLOAD_NOREQS the copy will be re-sent as a
> synchronous COPY. If application cancels an in-flight COPY,
> OFFLOAD_CANCEL is sent to the server (sending it as an async RPC in the
> context of the nfsid_workqueue).
>
> v8.
> - added patch 13 to handle reboot recovery of the server or network
> partition. this patch was a part of the initial "inter async" series
> but never got added to the async series. without this patch if the
> server goes away, thread that was doing the copy would be hanging
> waiting for the callback that would never arrive.
>
>
>
> Anna Schumaker (1):
> fs: Don't copy beyond the end of the file
>
> Olga Kornievskaia (12):
> NFS CB_OFFLOAD xdr
> NFS OFFLOAD_STATUS xdr
> NFS OFFLOAD_STATUS op
I'm still not sold on adding in offload status on the client without a way to use it. Can you rearrange this series so offload status is at the very end? That way we can add it in later, if there is ever an interface for copy statuses.
Anna
> NFS OFFLOAD_CANCEL xdr
> NFS COPY xdr handle async reply
> NFS add support for asynchronous COPY
> NFS handle COPY reply CB_OFFLOAD call race
> NFS export nfs4_async_handle_error
> NFS send OFFLOAD_CANCEL when COPY killed
> NFS handle COPY ERR_OFFLOAD_NO_REQS
> NFS add a simple sync nfs4_proc_commit after async COPY
> NFS recover from destination server reboot for copies
>
> fs/nfs/callback.h | 12 +++
> fs/nfs/callback_proc.c | 54 ++++++++++
> fs/nfs/callback_xdr.c | 81 ++++++++++++++-
> fs/nfs/client.c | 1 +
> fs/nfs/nfs42.h | 5 +-
> fs/nfs/nfs42proc.c | 251 ++++++++++++++++++++++++++++++++++++++++++++--
> fs/nfs/nfs42xdr.c | 189 +++++++++++++++++++++++++++++++---
> fs/nfs/nfs4_fs.h | 8 +-
> fs/nfs/nfs4client.c | 15 +++
> fs/nfs/nfs4file.c | 9 +-
> fs/nfs/nfs4proc.c | 38 ++++++-
> fs/nfs/nfs4state.c | 15 +++
> fs/nfs/nfs4xdr.c | 2 +
> fs/read_write.c | 3 +
> include/linux/nfs4.h | 2 +
> include/linux/nfs_fs.h | 11 ++
> include/linux/nfs_fs_sb.h | 4 +
> include/linux/nfs_xdr.h | 14 +++
> 18 files changed, 689 insertions(+), 25 deletions(-)
>
prev parent reply other threads:[~2018-04-20 17:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-13 17:03 [PATCH v8 00/13] NFS support for async intra COPY Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 01/13] fs: Don't copy beyond the end of the file Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 02/13] NFS CB_OFFLOAD xdr Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 03/13] NFS OFFLOAD_STATUS xdr Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 04/13] NFS OFFLOAD_STATUS op Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 05/13] NFS OFFLOAD_CANCEL xdr Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 06/13] NFS COPY xdr handle async reply Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 07/13] NFS add support for asynchronous COPY Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 08/13] NFS handle COPY reply CB_OFFLOAD call race Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 09/13] NFS export nfs4_async_handle_error Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 10/13] NFS send OFFLOAD_CANCEL when COPY killed Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 11/13] NFS handle COPY ERR_OFFLOAD_NO_REQS Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 12/13] NFS add a simple sync nfs4_proc_commit after async COPY Olga Kornievskaia
2018-04-13 17:03 ` [PATCH v8 13/13] NFS recover from destination server reboot for copies Olga Kornievskaia
2018-04-20 17:30 ` Anna Schumaker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=caa5e13f-ba11-e414-0f71-4c26d7572faa@gmail.com \
--to=schumaker.anna@gmail.com \
--cc=Trond.Myklebust@primarydata.com \
--cc=anna.schumaker@netapp.com \
--cc=kolga@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).