On Thu, Nov 30, 2017 at 3:18 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Tue, Nov 28, 2017 at 03:28:46PM -0500, Olga Kornievskaia wrote: >> On Mon, Nov 13, 2017 at 7:48 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: >> > On Fri, Nov 10, 2017 at 10:01:02AM -0500, Olga Kornievskaia wrote: >> >> On Fri, Nov 3, 2017 at 3:57 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> >> > Bruce, any comments on this version? >> >> >> >> Bruce, do you have any comments on this version? >> > >> > I don't yet, apologies. It is on my list to look at. >> > >> >> Any ideas as to when that would be? > > Sorry for the silence. I'll try to get it reviewed in time for 4.16. I hope I won't forget too much in 3months for this ;) > But I'm worrying about async behavior. Just the usual complaint: > > - A large copy could take anywhere from milliseconds to hours. With the sync copy your worry was with tying up the nfsd thread. Here each copy gets its own thread and doesn't interfere with other operations. So why worry? > - The only way the protocol gives to measure progress is > OFFLOAD_STATUS, but I'm pessimistic that we'll get a > corresponding copy_progress syscall interface that > applications will get patched to use. Doing a cp, never had a status info so what's different now. Interested folks can do as before ls -l dst_file to monitor progress. > So, currently the server's trying to avoid the problem by returning > short COPY results and hoping applications will handle that gracefully > (and that readahead and write behind will save performance). We have demonstrated that doing async copy performs significantly better (given large enough file size which was different between intra and inter copy but something like 16MB). Really there is no point in introducing an asynchronous copy unless you are doing all of it. > But I guess that won't work in the server-to-server case. Or would it? > I *think* you can just send one NOTIFY NOTIFY is only for "inter" server-to-server copy and we are currently reviewing "asynchronous intra" copy? > and then reuse the same stateid > in multiple COPYs, so maybe it's not any worse than in the single-server > case. No you can not reuse the same stateid in multiple COPY's (spec doesn't allow it). It has to uniquely identity the copy. Otherwise, when client receives a reply from the async COPY it doesn't know which out of those multiple copies to match it to. > That would be a lot simpler if it worked. > > --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
