[Samba] Samba and BTRFS server-side copy

[Jeremy Allison]

On Fri, Oct 28, 2016 at 02:02:57AM +0200, Saint Germain via samba wrote:
> 
> On linux, most current utilities like Nautilus (gvfs) still use SMB1 to
> connect, so there is no chance to trigger a server-side copy.

Oh, just checked the current gvfs source code to copy an
smb file. It does:

static gboolean
copy_file (GVfsBackendSmb *backend,
           GVfsJob *job,
           const char *from_uri,
           const char *to_uri)
{
  SMBCFILE *from_file, *to_file;
  char buffer[4096];
  size_t buffer_size;
  ssize_t res;
  char *p;
  gboolean succeeded;
  smbc_open_fn smbc_open;
  smbc_read_fn smbc_read;
  smbc_write_fn smbc_write;
  smbc_close_fn smbc_close;
  

  from_file = NULL;
  to_file = NULL;

  succeeded = FALSE;

  smbc_open = smbc_getFunctionOpen (backend->smb_context);
  smbc_read = smbc_getFunctionRead (backend->smb_context);
  smbc_write = smbc_getFunctionWrite (backend->smb_context);
  smbc_close = smbc_getFunctionClose (backend->smb_context);

Which clearly doesn't use the splice call. That's broken.

If there's anyone on the Gnome gvfs team please let
me know and let's get this fixed.

Looking around inside that source code I also see:

do_read (GVfsBackend *backend,
         GVfsJobRead *job,
         GVfsBackendHandle handle,
         char *buffer,
         gsize bytes_requested)
{
  GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend);
  ssize_t res;
  smbc_read_fn smbc_read;

  /* libsmbclient limits blocksize to (64*1024)-2 for Windows servers,
   * let's do the same here to achieve reasonable performance. (#588391)
   *
   * TODO: port to pull mechanism (#592468)
   */
  if (bytes_requested > 65534)
    bytes_requested = 65534;

  smbc_read = smbc_getFunctionRead (op_backend->smb_context);
  res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, buffer, bytes_requested);

which is also completely broken and wrong. The read call
can take any arbitrary size and the both the libsmbclient
SMB1 and SMB2 engines will break this down into as many
simultaneous on the wire calls as needed to pipeline
the reads / writes.

Restricting this to 65534 is *insane* and slow. That
whole chunk of code restricting the size needs to be
removed.