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. But I'm worrying about async behavior. Just the usual complaint: - A large copy could take anywhere from milliseconds to hours. - 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. 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). But I guess that won't work in the server-to-server case. Or would it? I *think* you can just send one NOTIFY and then reuse the same stateid in multiple COPYs, so maybe it's not any worse than in the single-server case. 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
