On 11/04/2013 06:31 AM, Steve French wrote: > On Wed, Oct 30, 2013 at 6:03 PM, Pádraig Brady <[email protected]> wrote: >> On 10/17/2013 12:36 AM, Steve French wrote: >>> cp --reflink opens the target file for O_WRONLY before invoking the >>> (BTRFS) ioctl for clone file, but for copy offload over the network >>> the SMB2 specification requires that the target file be open O_RDWR. >>> >>> I may be able to upgrade the target file handle on the fly by >>> reopening it in cifs.ko, and of course I can write an SMB2/SMB3 >>> specific copy command, but it would be preferable to allow use of cp >>> --reflink since so many people are familiar with it. >>> >>> There is quite a bit of flexibility in server side copy offload - >>> more than cp an offer, especially when using SMB3 or later dialects >>> (e.g. in number of chunks sent at one time, chunk size, attributes >>> copied, and even whether to use T10 style offload), but still it would >>> be nice to support "cp --reflink" over the network. Any ideas on >>> this? >>> >>> After looking at copy.c in coreutils for cp - I couldn't think of any >>> trivial way to force cp to open the target RW. >>> >>> Ideas? >>> >> >> Hi I'm one of the coreutils maintainers >> and was behind the --reflink option to cp. >> >> I'm not following the above discussion. >> cp --reflink currently just calls the btrfs ioctl, >> for src and dest fds, the latter which is opened O_WRONLY >> irrespective of --reflink. >> >> Are you saying that cifs is supporting this same IOCTL >> as a high level "copy efficiently" function? >> So you could `alias cp='cp --reflink=auto'` to copy >> efficiently as possible? >> >> There were separate reflink() and copyfile() >> syscalls mooted recently, for which the latter would >> be best suited to efficient backend copying on network file systems. >> I would envisage cp trying to use copyfile() by default >> if it ever became available.
> Couple quick comments (I would love to followup more). > > Obviously refcopy/copy-offload/server-side-copy (whatever you call it) > - is most important for network file copies, backup, provisioning etc. > It is somewhat helpful for local file systems (e.g. btrfs clone does > help improve copy speed - but no where near as much as over a network > mount where you get an order of magnitude more savings). > > I have tested using cp --reflink over cifs mounts (actually smb2 and > smb3 mounts using cifs.ko) with patch currently in linux-next (not > quite complete patch series - missing some error handling, and buffer > negotiation changes that are independent of things you would probably > care about). - and they work fine (to most current Samba, and all > Windows since about Windows 2003, Windows 7, Windows 8, Windows 2012 > etc. - and probably all major NAS boxes - NetApp etc are also fine). > > cp --reflink simply calls an ioctl, and easy to handle one for me (in cifs.ko) Ok cool. I'm CC'ing [email protected] where we discuss such ideas/patches for GNU coreutils. Note that --reflink has different CoW semantics than a normal copy and so would probably not be the interface used here. I would think that cp might use some introspection as to whether to use the "smb_copy_offload" ioctl or not, iff it had a negligible cost. > Preliminary performance data is good. > > Ideally we should match some higher level syscalls to the behaviors > possible with SMB2/SMB3 (since that is the most common network file > system) - there are other copy offload features which are not exposed > by cp --reflink > That (i.e. the copyfile() level call or equivalent I mentioned above) would be much better and more likely to be incorporated. thanks, Pádraig.
