> On Sep 4, 2020, at 10:29 AM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Fri, Sep 04, 2020 at 10:07:22AM -0400, Chuck Lever wrote: >> My primary concern is that the result of a file copy operation should >> look the same on NFS/TCP (with READ_PLUS) and NFS/RDMA (with SEEK_DATA/HOLE). > > I'm not sure what you mean. > > I don't see the spec providing any guarantee of consistency between > READ_PLUS and SEEK. IMO this is an implementation quality issue, not a spec compliance issue. > It also doesn't guarantee that the results tell you > anything about how the file is actually stored--a returned "hole" could > represent an unallocated segment, or a fully allocated segment that's > filled with zeroes, or some combination. Understood, but the resulting copied file should look the same whether it was read from the server using READ_PLUS or SEEK_DATA/HOLE. > So, for example, if you implemented an optimized copy that used > ALLOCATE, DEALLOCATE, SEEK and/or READ_PLUS to avoid reading and writing > a lot of zeroes--there's no guarantee that the target file would end up > allocated in the same way as the source. -- Chuck Lever
