Re: [PATCH v5 00/10] NFSD support for asynchronous COPY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux