On Thu, Feb 15, 2018 at 05:18:55PM -0500, Olga Kornievskaia wrote: > On Fri, Feb 2, 2018 at 4:45 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > > Is it really OK to do a COPY with a delegation stateid? That sounds > > messy if the delegation is revoked partway through the copy. > > Yes, according to the spec, it is ok to use any of the stateids. > > RFC 7862 15.2.3 > The ca_dst_stateid MUST refer to a stateid that is valid for a WRITE > operation and follows the rules for stateids in Sections 8.2.5 and > 18.32.3 of [RFC5661].... while for an intra-server copy > ca_src_stateid MUST refer > to a stateid that is valid for a READ operation and follows the rules > for stateids in Sections 8.2.5 and 18.22.3 of [RFC5661]. > > 8.2.5 is the section that says in the decreasing priority to choose > delegation stateid, locking stateid, open stateid. > > Trying to deal with the delegation stateid seems to be rather complex. > Here's what I could do (which I mentioned before already): > 1. possibly change the client to never use a delegation stateid. > 2. for CLOSE/UNLOCK send back ERR_DELAY if copy list is not empty. > 3. for DELEGRETURN (or when the server initiates CB_RECALL?) kill any > on-going copies. Change the nfsd copy to send a reply if it was killed > with a signal. What I'm not sure if when it's killed I get any partial > bytes from the VFS, I don't think so. I think in that case, the only > thing that I might reply with is a 0bytes copy. And whatever client > that did sent a copy with a delegation stateid would deal with > restarting it with a different stateid. > > Having said all that, I'd like to ask why do you think handling > CLOSE/LOCKU/DELEGRETURN should be any different for async copy vs what > is currently there for the synchronous copy. Right now if the server > receives those operations it does nothing to the on-going synchronous > copy. Or for that matter, why should it be different from READ and WRITE--looks like those can also continue executing after a close, too. So, good point. > As you noted, the async copy takes a reference on the parent stateid > so the state won't go away while the async copy is going on. Why not > keep async copy same as the synchronous one? OK, so maybe it's not such a big deal. I'm still confused about the delegation case, though: a copy can take a very long time, so we can't just wait for the copy to end before revoking the delegation. So do we allow the copy to continue indefinitely even after the delegation stateid it was initiated with has long ago been revoked? Maybe it's not a problem. I guess I'm having trouble remembering why copies (or IO in general) uses stateids in the first place.... --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
