Re: [PATCH v4 2/5] NFSD: Add READ_PLUS data support

[Bruce Fields <bfields@fieldses.org>]

On Fri, Sep 04, 2020 at 10:58:43AM -0400, Chuck Lever wrote:
> > What do you think might go wrong otherwise?
> 
> I don't see a data corruption issue here, if that's what
> you mean.
> 
> Suppose the server has a large file with a lot of holes,
> and these holes are all unallocated. This might be
> typical of a container image.
> 
> Suppose further the client is able to punch holes in a
> destination file as a thin provisioning mechanism.
> 
> Now, suppose we copy the file via TCP/READ_PLUS, and
> that preserves the holes.
> 
> Copy with RDMA/SEEK_HOLE and maybe it doesn't preserve
> holes. The destination file is now significantly larger
> and less efficiently stored.
> 
> Or maybe it's the other way around. Either way, one
> mechanism is hole-preserving and one isn't.
> 
> A quality implementation would try to preserve holes as
> much as possible so that the server can make smart storage
> provisioning decisions.

OK, I can see that, thanks.

So, I was trying to make sure we handle cases where SEEK results are
weirdly aligned or segments returned are very small.  I don't think
that'll happen with any "normal" setup, I think it probably requires
strange FUSE filesystems or unusual races or malicious users or some
combination thereof.  So suboptimal handling is OK, I just don't want to
violate the protocol or crash or hang or something.

I'm not seeing the RDMA connection, by the way.  SEEK and READ_PLUS
should work the same over TCP and RDMA.

--b.