From: "J. Bruce Fields" <bfields@redhat.com>
To: Anna Schumaker <Anna.Schumaker@Netapp.com>
Cc: Olga Kornievskaia <aglo@umich.edu>,
Olga Kornievskaia <kolga@netapp.com>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v5 00/10] NFSD support for asynchronous COPY
Date: Mon, 16 Oct 2017 12:49:35 -0400 [thread overview]
Message-ID: <20171016164935.GD19720@parsley.fieldses.org> (raw)
In-Reply-To: <b4f0f30e-c19e-1b2f-7379-d859b4b5ff49@Netapp.com>
On Mon, Oct 16, 2017 at 09:13:20AM -0400, Anna Schumaker wrote:
>
>
> On 10/13/2017 08:09 PM, Olga Kornievskaia wrote:
> > On Fri, Oct 13, 2017 at 5:26 PM, J. Bruce Fields <bfields@redhat.com> wrote:
> >> On Fri, Oct 13, 2017 at 04:54:02PM -0400, Olga Kornievskaia wrote:
> >>> To do asynchronous copies, NFSD creates a new kthread to handle the request.
> >>> Upon receiving the COPY, it generates a unique copy stateid (stored in a
> >>> global list for keeping track of state for OFFLOAD_STATUS to be queried by),
> >>> starts the thread, and replies back to the client. nfsd4_copy arguments that
> >>> are allocated on the stack are copies for the kthread.
> >>>
> >>> In the async copy handler, it calls into VFS copy_file_range() (for synch
> >>> we keep the 4MB chunk and requested size for the async copy). If error is
> >>> encountered it's saved but also we save the amount of data copied so far.
> >>> Once done, the results are queued for the callback workqueue and sent via
> >>> CB_OFFLOAD.
> >>>
> >>> When the server received an OFFLOAD_CANCEL, it will find the kthread running
> >>> the copy and will send a SIGPENDING and kthread_stop() and it will interrupt
> >>> the ongoing do_splice() and once vfs returns we are choosing not to send
> >>> the CB_OFFLOAD back to the client.
> >>>
> >>> When the server receives an OFFLOAD_STATUS, it will find the kthread running
> >>> the copy and will query the i_size_read() of the associated filehandle of
> >>> the destination file and return the result.
> >>
> >> That assumes we're copying into a previously empty file?
> >
> > Sigh. Alright, then it's back to my original solution where I broke
> > everything into 4MB calls and kept track of bytes copies so far.
>
> Do they have to be 4MB calls? Assuming clients don't need a super-accurate results, you could probably use a larger copy size and still have decent copy performance.
Sure, we could. Do we have reason to believe there's an advantage to
larger sizes?
--b.
next prev parent reply other threads:[~2017-10-16 16:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 20:54 [PATCH v5 00/10] NFSD support for asynchronous COPY Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 01/10] NFSD CB_OFFLOAD xdr Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 02/10] NFSD OFFLOAD_STATUS xdr Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 03/10] NFSD OFFLOAD_CANCEL xdr Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 04/10] NFSD xdr callback stateid in async COPY reply Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 05/10] NFSD first draft of async copy Olga Kornievskaia
2017-10-14 13:45 ` Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 06/10] NFSD return nfs4_stid in nfs4_preprocess_stateid_op Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 07/10] NFSD create new stateid for async copy Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 08/10] NFSD handle OFFLOAD_CANCEL op Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 09/10] NFSD support OFFLOAD_STATUS Olga Kornievskaia
2017-10-13 20:54 ` [PATCH v5 10/10] NFSD stop queued async copies on client shutdown Olga Kornievskaia
2017-10-13 21:26 ` [PATCH v5 00/10] NFSD support for asynchronous COPY J. Bruce Fields
2017-10-14 0:09 ` Olga Kornievskaia
2017-10-16 13:13 ` Anna Schumaker
2017-10-16 13:37 ` Mauricio Tavares
2017-10-16 16:49 ` J. Bruce Fields [this message]
2017-10-16 19:25 ` Olga Kornievskaia
2017-10-23 21:48 ` Olga Kornievskaia
2017-10-23 22:39 ` Olga Kornievskaia
2017-10-24 13:35 ` J. Bruce Fields
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=20171016164935.GD19720@parsley.fieldses.org \
--to=bfields@redhat.com \
--cc=Anna.Schumaker@Netapp.com \
--cc=aglo@umich.edu \
--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).