On Thu, Sep 28, 2017 at 03:21:54PM -0400, Olga Kornievskaia wrote: > On Thu, Sep 28, 2017 at 3:12 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > > On Thu, Sep 28, 2017 at 01:29:42PM -0400, Olga Kornievskaia wrote: > >> Generate a new stateid to be used for reply to the asynchronous > >> COPY (this would also be used later by COPY_NOTIFY as well). > >> Associate the stateid with the parent OPEN/LOCK/DELEG stateid > >> that can be freed during the free of the parent stateid. However, > >> right now deciding to bind the lifetime to when the vfs copy > >> is done. This way don't need to keep the nfsd_net structure for > >> the callback. The drawback is that time copy state information > >> is available for query by OFFLOAD_STATUS is slightly less. > > > > I don't think we're under any obligation to handle OFFLOAD_STATUS after > > the copy is done, are we? > > It depends on how you define “copy is done”. I’d say copy is done once the > server sent the CB_OFFLOAD. But I’m choosing to clear the state once the > vfs_copy_file_range() is done. Then the callback is queued up (what if > there is wait until the callback can be processed) and there is a period > where if the client were to send a OFFLOAD_STATUS it should get the > bytes representing the full copy but instead the client will get an error back. > > I was worried about what if some implementation depend on querying for > the status and stopping to poll only when they received that all bytes were > copied and they might not get that with how the server is coded right now? I don't see the spec providing any guarantee that the copy status be kept around any minimum length of time, so I don't think a client would be correct to do that. --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
