On Mon, Oct 16, 2017 at 12:49 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > 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? I wouldn't think there'd be a large enough performance advantage with a larger size and there'd be worse OFFLOAD_STATUS information. I'm sure there is a setup cost for calling into do_splice() and the cost of doing a function call but I'd like they would be small. -- 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
