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.
