Subject: Re: [nfsv4] 4.2 COPY op questions

From: David Noveck <[email-masked]>
Date: Fri, 1 Aug 2014 11:13:34 -0400

> If the client that has initiated a server-to-server copy holds a write
delegation it may also hold unwritten data that the source server has not
seen.  If the COPY op does not cause a delegation recall the client would
need to ensure that this unwritten data is flushed prior to initiating the
copy.  That might be a quality of implementation detail.

it sounds to me like you might copy an out-of-date file.  it also possible
that some quasi-random set of writes get back to the source server so that
you have a corrupt copy of the source file on the destination.   Data
corruption is not a detail.

> The possibility exists to use NFSv4.x as the Copy Protocol.

I don't think this depends on the copy protocol used.  If the source and
destination servers are the same and some sort of local copy optimization
is used, the same fundamental issue arises.  Some set of updates to the
file may not be visible on the source server.

> unless it is expected that the READ on the destination server can skip
the OPEN by using arguments in the COPY op

I think the idea of the destination server using the client-done OPEN is
the fundamental problem.

Normally, a server will not consider an OPEN done by a client holding a
delegation as conflicting with that delegation.  The assumption is that the
client will be doing the IO and has the opportunity to look at any updates
done on the client and not yet propagated to the server.  The
destination server using the client-provided statetid is in a different
situation.

> I think it would be helpful if the spec had additional clarifying
language here detailing the expected behavior and relationship to
delegations.

It would certainly be unhelpful if it didn't.

>
>
>
>
>
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 1 Aug 2014 12:13:59 -0400

> corruption is not a detail.

No, but recalling a delegation just in order to remind the client that
it needs to write back data before sending the COPY call seems harsh.
Perhaps just a little note in the RFC to the implementor that if the
client doesn't write back all the data then it will see a corrupt
copy?

Any delegations held by 3rd party clients will have been recalled on file OPEN.

> destination servers are the same and some sort of local copy optimization is
> used, the same fundamental issue arises.  Some set of updates to the file
> may not be visible on the source server.
>
>> unless it is expected that the READ on the destination server can skip the
>> OPEN by using arguments in the COPY op
>
> I think the idea of the destination server using the client-done OPEN is the
> fundamental problem.
>
> done on the client and not yet propagated to the server.  The destination
> server using the client-provided statetid is in a different situation.
>
>> I think it would be helpful if the spec had additional clarifying language
>> here detailing the expected behavior and relationship to delegations.
>