Re: vfs: move btrfs clone ioctls to common code

[Steve French <smfrench@gmail.com>]

On Thu, Dec 3, 2015 at 4:30 AM, Christoph Hellwig <hch@lst.de> 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