From patchwork Tue Nov 26 19:41:36 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 3240761 Return-Path: X-Original-To: patchwork-cifs-client@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id DA77C9F3AE for ; Tue, 26 Nov 2013 19:41:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A998320453 for ; Tue, 26 Nov 2013 19:41:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B963220444 for ; Tue, 26 Nov 2013 19:41:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756477Ab3KZTlj (ORCPT ); Tue, 26 Nov 2013 14:41:39 -0500 Received: from mail-pb0-f43.google.com ([209.85.160.43]:58968 "EHLO mail-pb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754288Ab3KZTli (ORCPT ); Tue, 26 Nov 2013 14:41:38 -0500 Received: by mail-pb0-f43.google.com with SMTP id rq2so8671373pbb.2 for ; Tue, 26 Nov 2013 11:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g5hCKAVugFtZAp+WJ/aQGfUj+7upQLSoBTOD3zI/CC0=; b=j0BUaxe7rzt/mByWuJ0fWRu6a+FC0xntbrgGK/7G0Fy2nxGGmt+ANu78tRKSFdtxCX 8pwuQGUzMYBPl6SoPIocfWVEv3oIN/oIaDeTlVIyJGE+kHOiRtAleUy+I9GFUjzCsWyF 17diU5V8U2i92TkPg1kQkvkhSCzxIyFEh0F3hyKyGEObYVe4QXB6gPPRQE/uQbu0nYSx HKkVwCI6dMOHXec6h50x/ArpF1Og4Z+uyWfWdKtgJs6MBBK3UCsZgaOkc5dbYleKcoyX Gk3JykNdHcf06WkMoBG5D1st3gXxQ34mzqD+qyXbbC1krxyYfEv+UVWGABgkfHytkt/O KMfw== MIME-Version: 1.0 X-Received: by 10.68.190.229 with SMTP id gt5mr1004311pbc.177.1385494897224; Tue, 26 Nov 2013 11:41:37 -0800 (PST) Received: by 10.68.143.10 with HTTP; Tue, 26 Nov 2013 11:41:36 -0800 (PST) Date: Tue, 26 Nov 2013 13:41:36 -0600 Message-ID: Subject: Subject: [PATCH] [CIFS] Do not use btrfs refcopy ioctl for SMB2 copy offload From: Steve French To: samba-technical , "linux-cifs@vger.kernel.org" , linux-fsdevel Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Resending since subject line was dropped (empty) first time ---------- Forwarded message ---------- From: Steve French Date: Mon, Nov 25, 2013 at 9:59 AM Subject: [PATCH] [CIFS] Do not use btrfs refcopy ioctl for SMB2 copy offload To: samba-technical , "linux-cifs@vger.kernel.org" , linux-fsdevel Cc: David Disseldorp , Christoph Hellwig From f19e84df37bda502a2248d507a9cf2b9e693279e Mon Sep 17 00:00:00 2001 From: Steve French Date: Sun, 24 Nov 2013 21:53:17 -0600 Subject: [PATCH] [CIFS] Do not use btrfs refcopy ioctl for SMB2 copy offload Change cifs.ko to using CIFS_IOCTL_COPYCHUNK instead of BTRFS_IOC_CLONE to avoid confusion about whether copy-on-write is required or optional for this operation. SMB2/SMB3 copyoffload had used the BTRFS_IOC_CLONE ioctl since they both speed up copy by offloading the copy rather than passing many read and write requests back and forth and both have identical syntax (passing file handles), but for SMB2/SMB3 CopyChunk the server is not required to use copy-on-write to make a copy of the file (although some do), and Christoph has commented that since CopyChunk does not require copy-on-write we should not reuse BTRFS_IOC_CLONE. This patch renames the ioctl to use a cifs specific IOCTL CIFS_IOCTL_COPYCHUNK. This ioctl is particularly important for SMB2/SMB3 since large file copy over the network otherwise can be very slow, and with this is often more than 100 times faster putting less load on server and client. Note that if a copy syscall is ever introduced, depending on its requirements/format it could end up using one of the other three methods that CIFS/SMB2/SMB3 protocol allows for copy offload, but this method is particularly useful for file copy and broadly supported (not just by Samba server). Signed-off-by: Steve French Reviewed-by: Jeff Layton Reviewed-by: David Disseldorp --- fs/cifs/ioctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) default: From f19e84df37bda502a2248d507a9cf2b9e693279e Mon Sep 17 00:00:00 2001 From: Steve French Date: Sun, 24 Nov 2013 21:53:17 -0600 Subject: [PATCH] [CIFS] Do not use btrfs refcopy ioctl for SMB2 copy offload Change cifs.ko to using CIFS_IOCTL_COPYCHUNK instead of BTRFS_IOC_CLONE to avoid confusion about whether copy-on-write is required or optional for this operation. SMB2/SMB3 copyoffload had used the BTRFS_IOC_CLONE ioctl since they both speed up copy by offloading the copy rather than passing many read and write requests back and forth and both have identical syntax (passing file handles), but for SMB2/SMB3 CopyChunk the server is not required to use copy-on-write to make a copy of the file (although some do), and Christoph has commented that since CopyChunk does not require copy-on-write we should not reuse BTRFS_IOC_CLONE. This patch renames the ioctl to use a cifs specific IOCTL CIFS_IOCTL_COPYCHUNK. This ioctl is particularly important for SMB2/SMB3 since large file copy over the network otherwise can be very slow, and with this is often more than 100 times faster putting less load on server and client. Note that if a copy syscall is ever introduced, depending on its requirements/format it could end up using one of the other three methods that CIFS/SMB2/SMB3 can do for copy offload, but this method is particularly useful for file copy and broadly supported (not just by Samba server). Signed-off-by: Steve French Reviewed-by: Jeff Layton Reviewed-by: David Disseldorp --- fs/cifs/ioctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/cifs/ioctl.c b/fs/cifs/ioctl.c index 409b45e..7749230 100644 --- a/fs/cifs/ioctl.c +++ b/fs/cifs/ioctl.c @@ -26,13 +26,15 @@ #include #include #include -#include #include "cifspdu.h" #include "cifsglob.h" #include "cifsproto.h" #include "cifs_debug.h" #include "cifsfs.h" +#define CIFS_IOCTL_MAGIC 0xCF +#define CIFS_IOC_COPYCHUNK_FILE _IOW(CIFS_IOCTL_MAGIC, 3, int) + static long cifs_ioctl_clone(unsigned int xid, struct file *dst_file, unsigned long srcfd, u64 off, u64 len, u64 destoff) { @@ -213,7 +215,7 @@ long cifs_ioctl(struct file *filep, unsigned int command, unsigned long arg) cifs_dbg(FYI, "set compress flag rc %d\n", rc); } break; - case BTRFS_IOC_CLONE: + case CIFS_IOC_COPYCHUNK_FILE: rc = cifs_ioctl_clone(xid, filep, arg, 0, 0, 0); break; default: -- 1.8.3.1