On Thu, Dec 3, 2015 at 4:30 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Dec 02, 2015 at 11:40:13AM -0600, Steve French wrote: >> If the copy_file_range is allowed to use any offload mechanism then >> cifs.ko could be changed as follows, to fallback among the three >> possible mechanisms depending on what the target supports. > > How reliable are the fallbacks? E.g. for clones we usually have alignment > restrictions that we'd need to communicate back, and cifs currently > doesn't have client side checks for those. I am not worried about fallback inconsistency for the current two options, if block refcounting is not supported we will know before we issue the request, and the fallback copy chunk has few restrictions. When we add ODX there may be additional alignments restrictions, but don't know until we investigate more. Although we can query alignment over CIFS and SMB3, it is less important to know over a network file system than a block device, and unlikely to be a restriction. Although the protocol does not restrict the maximum chunk size, the server can return an error indicating the maximum supported chunk size, allowing the client to retry with the size of chunks the server requests. To match existing server behavior with reasonable defaults for common servers - the cifs client uses 16 chunks of 1MB each for each FSCTL_SRV_COPYCHUNK_WRITE request sent on the wire. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
