From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 00:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 23904@debbugs.gnu.org Cc: sbaugh@catern.com, Kieran Colford X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.146776617819393 (code B ref -1); Wed, 06 Jul 2016 00:50:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 Jul 2016 00:49:38 +0000 Received: from localhost ([127.0.0.1]:38738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKb21-00052j-Sn for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKb1y-00052T-72 for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKb1r-0000Rt-Eq for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1r-0000Rm-BD for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1o-0000Kr-Lm for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKb1l-0000Qi-DD for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:24 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1l-0000Q9-4R for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:21 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B59131614C4; Tue, 5 Jul 2016 17:49:19 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SFeRXCk90mgA; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E03CE1614AD; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9qTC7WVSxn1m; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) Received: from [192.168.0.35] (89-159-79-138.rev.numericable.fr [89.159.79.138]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1EDCB1613C2; Tue, 5 Jul 2016 17:49:16 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> From: Paul Eggert Message-ID: <577C5588.3060608@cs.ucla.edu> Date: Wed, 6 Jul 2016 02:49:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1467745602.28158.17.camel@kcolford.com> Content-Type: multipart/mixed; boundary="------------070407000101080704040409" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) This is a multi-part message in MIME format. --------------070407000101080704040409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tags: patch The attached proposed patch to Emacs master builds on a suggestion by Kieran Colford. Kieran, can you please comment on its two FIXMEs? --------------070407000101080704040409 Content-Type: text/x-patch; name="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" >From 4b2a532a87ec2a21afc205b83db4a779664ccd20 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 6 Jul 2016 02:42:58 +0200 Subject: [PATCH] copy-file now uses GNU/Linux file cloning >From a suggestion by Kieran Colford in: http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00191.html * configure.ac: Check for linux/fs.h. * src/fileio.c [HAVE_LINUX_FS_H]: Include sys/ioctl.h and linux/fs.h. (clone_file): New function. (Fcopy_file): Use it. --- configure.ac | 1 + src/fileio.c | 64 ++++++++++++++++++++++++++++++++++++++++++------------------ 2 files changed, 46 insertions(+), 19 deletions(-) diff --git a/configure.ac b/configure.ac index aaddfcd..1798fa3 100644 --- a/configure.ac +++ b/configure.ac @@ -1636,6 +1636,7 @@ AC_DEFUN dnl checks for header files AC_CHECK_HEADERS_ONCE( + linux/fs.h malloc.h sys/systeminfo.h sys/sysinfo.h diff --git a/src/fileio.c b/src/fileio.c index b1f9d3c..c2e3a18 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -52,6 +52,11 @@ along with GNU Emacs. If not, see . */ #include "region-cache.h" #include "frame.h" +#ifdef HAVE_LINUX_FS_H +# include +# include +#endif + #ifdef WINDOWSNT #define NOMINMAX 1 #include @@ -1828,6 +1833,24 @@ barf_or_query_if_file_exists (Lisp_Object absname, bool known_to_exist, } } +/* Copy all data to DEST from SOURCE if possible. Return true if OK. */ +static bool +clone_file (int dest, int source) +{ +#ifdef FICLONE + /* FIXME: Might this ioctl take a long time if the file is very + large? Is the ioctl interruptible? If so, what happens if the + ioctl is interrupted by a signal? Might it partially copy the + file? */ + /* FIXME: Does this ioctl truncate the output file to be the same + size as the input file, if the output file already exists and is + larger than the input file? */ + if (ioctl (dest, FICLONE, source) == 0) + return true; +#endif + return false; +} + DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6, "fCopy file: \nGCopy %s to file: \np\nP", doc: /* Copy FILE to NEWNAME. Both args must be strings. @@ -1988,28 +2011,31 @@ permissions. */) oldsize = out_st.st_size; } - immediate_quit = 1; - QUIT; - while (true) + if (! clone_file (ofd, ifd)) { - char buf[MAX_ALLOCA]; - ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); - if (n < 0) - report_file_error ("Read error", file); - if (n == 0) - break; - if (emacs_write_sig (ofd, buf, n) != n) - report_file_error ("Write error", newname); - newsize += n; - } + immediate_quit = 1; + QUIT; + while (true) + { + char buf[MAX_ALLOCA]; + ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); + if (n < 0) + report_file_error ("Read error", file); + if (n == 0) + break; + if (emacs_write_sig (ofd, buf, n) != n) + report_file_error ("Write error", newname); + newsize += n; + } - /* Truncate any existing output file after writing the data. This - is more likely to work than truncation before writing, if the - file system is out of space or the user is over disk quota. */ - if (newsize < oldsize && ftruncate (ofd, newsize) != 0) - report_file_error ("Truncating output file", newname); + /* Truncate any existing output file after writing the data. This + is more likely to work than truncation before writing, if the + file system is out of space or the user is over disk quota. */ + if (newsize < oldsize && ftruncate (ofd, newsize) != 0) + report_file_error ("Truncating output file", newname); - immediate_quit = 0; + immediate_quit = 0; + } #ifndef MSDOS /* Preserve the original file permissions, and if requested, also its -- 2.5.5 --------------070407000101080704040409-- From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 02:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert , 23904@debbugs.gnu.org Cc: sbaugh@catern.com, Kieran Colford Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.146777312929766 (code B ref 23904); Wed, 06 Jul 2016 02:46:01 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 02:45:29 +0000 Received: from localhost ([127.0.0.1]:38749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKcq8-0007k2-UL for submit@debbugs.gnu.org; Tue, 05 Jul 2016 22:45:29 -0400 Received: from forward4j.cmail.yandex.net ([5.255.227.22]:35224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKcq7-0007jo-8U for 23904@debbugs.gnu.org; Tue, 05 Jul 2016 22:45:27 -0400 Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward4j.cmail.yandex.net (Yandex) with ESMTP id 20A7820F3B; Wed, 6 Jul 2016 05:45:20 +0300 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 8976D1B60347; Wed, 6 Jul 2016 05:45:19 +0300 (MSK) Received: by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id cezFP5MXkZ-jIh81oXg; Wed, 06 Jul 2016 05:45:18 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1467773118; bh=zyRF0YQAd89hjlJZIVri5oVKuQz1tYO00faC9DiG0Go=; h=Subject:To:References:Cc:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=R43ueisOuRsU7gdXYDgWngBqFzWvUFo8/L+xmXJgGzTyfYuh/RZHI6iYwWlLGggtK 8+L+6dedeFnkrGmA0r6FxdMif5bQ0zxz7pwQoVRJygypW9sPq9lIKbc0y3NG63D/b+ xkfxjMzOg6OuJBNtNcj6Mru6nrGfQhQhtK2l3d+M= Authentication-Results: smtp14.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0 References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> From: Dmitry Antipov Message-ID: <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> Date: Wed, 6 Jul 2016 05:45:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <577C5588.3060608@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 07/06/2016 03:49 AM, Paul Eggert wrote: > The attached proposed patch to Emacs master builds on a suggestion by Kieran Colford. IMHO this should use FICLONERANGE in a loop where you can handle errors and use process_pending_signals as usual. Dmitry From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations In-Reply-To: <577C5588.3060608@cs.ucla.edu> Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 05:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 23904@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.146778437714295 (code B ref -1); Wed, 06 Jul 2016 05:53:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 Jul 2016 05:52:57 +0000 Received: from localhost ([127.0.0.1]:38797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKflZ-0003iV-1O for submit@debbugs.gnu.org; Wed, 06 Jul 2016 01:52:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36973) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKflW-0003iE-Sw for submit@debbugs.gnu.org; Wed, 06 Jul 2016 01:52:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKflQ-0007ih-RS for submit@debbugs.gnu.org; Wed, 06 Jul 2016 01:52:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKflQ-0007id-OO for submit@debbugs.gnu.org; Wed, 06 Jul 2016 01:52:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKflP-0005Fw-MG for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 01:52:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKflM-0007i8-FV for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 01:52:47 -0400 Received: from plane.gmane.org ([80.91.229.3]:48401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKflM-0007hJ-8q for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 01:52:44 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bKflJ-0008Fi-4F for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2016 07:52:41 +0200 Received: from dial-190008.pool.broadband44.net ([212.46.190.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jul 2016 07:52:41 +0200 Received: from eller.helmut by dial-190008.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jul 2016 07:52:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ From: Helmut Eller Date: Wed, 06 Jul 2016 07:52:24 +0200 Lines: 13 Message-ID: References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dial-190008.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:IQmjE8n030wcQdEqFxR9iXGbZUI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) On Wed, Jul 06 2016, Dmitry Antipov wrote: > On 07/06/2016 03:49 AM, Paul Eggert wrote: > >> The attached proposed patch to Emacs master builds on a suggestion >> by Kieran Colford. > > IMHO this should use FICLONERANGE in a loop where you can > handle errors and use process_pending_signals as usual. This might also be a use case for sendfile(2). Helmut From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 11:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Antipov , 23904@debbugs.gnu.org Cc: sbaugh@catern.com, Kieran Colford Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.146780572619695 (code B ref 23904); Wed, 06 Jul 2016 11:49:01 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 11:48:46 +0000 Received: from localhost ([127.0.0.1]:38884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKlJt-00057b-JW for submit@debbugs.gnu.org; Wed, 06 Jul 2016 07:48:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKlJr-00057N-9w for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 07:48:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 487A51614BC; Wed, 6 Jul 2016 04:48:37 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RfVVPXUhf2Ip; Wed, 6 Jul 2016 04:48:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 732241614C8; Wed, 6 Jul 2016 04:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5caQhV2k36Ig; Wed, 6 Jul 2016 04:48:33 -0700 (PDT) Received: from [192.168.0.35] (89-159-79-138.rev.numericable.fr [89.159.79.138]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5F9531614BC; Wed, 6 Jul 2016 04:48:32 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> From: Paul Eggert Message-ID: <577CF00A.80707@cs.ucla.edu> Date: Wed, 6 Jul 2016 13:48:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> Content-Type: multipart/mixed; boundary="------------030504080808070801020508" X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) This is a multi-part message in MIME format. --------------030504080808070801020508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 07/06/2016 04:45 AM, Dmitry Antipov wrote: > IMHO this should use FICLONERANGE in a loop where you can > handle errors and use process_pending_signals as usual. Thanks, that suggestion should resolve the FIXME about how FICLONE behaves when the output file is already larger than the input. However, what should the clone chunk size be,each time through the loop? I don't use btrfs so I don't know what a good size would be. A downside of the suggestion is that the file copy won't be atomic. However, the existing code isn't atomic, so this is nothing new. Revised patch attached. Basically untested, since I don't use any file systems that support FIOCLONERANGE. The patch still has FIXMEs for what happens if the FIOCLONERANGE ioctl is interrupted by a signal, and for a good clone chunk size (the patch guesses 1 GiB). --------------030504080808070801020508 Content-Type: text/x-patch; name="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" >From 9c60f6f603563c335737102fc54609b837f5d02a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 6 Jul 2016 12:44:46 +0200 Subject: [PATCH] copy-file now uses GNU/Linux file cloning >From a suggestion by Kieran Colford (see Bug#23904). * configure.ac: Check for linux/fs.h. * src/fileio.c [HAVE_LINUX_FS_H]: Include sys/ioctl.h and linux/fs.h. (clone_file_range): New function. (Fcopy_file): Use it. --- configure.ac | 1 + src/fileio.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 50 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index aaddfcd..1798fa3 100644 --- a/configure.ac +++ b/configure.ac @@ -1636,6 +1636,7 @@ AC_DEFUN dnl checks for header files AC_CHECK_HEADERS_ONCE( + linux/fs.h malloc.h sys/systeminfo.h sys/sysinfo.h diff --git a/src/fileio.c b/src/fileio.c index b1f9d3c..f980247 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -52,6 +52,11 @@ along with GNU Emacs. If not, see . */ #include "region-cache.h" #include "frame.h" +#ifdef HAVE_LINUX_FS_H +# include +# include +#endif + #ifdef WINDOWSNT #define NOMINMAX 1 #include @@ -1828,6 +1833,23 @@ barf_or_query_if_file_exists (Lisp_Object absname, bool known_to_exist, } } +/* Copy data to DEST from SOURCE if possible, starting at byte offset + OFF and continuing for LENGTH bytes. Return true if OK. */ +static bool +clone_file_range (int dest, int source, off_t off, off_t length) +{ +#ifdef FICLONERANGE + /* FIXME: Is the ioctl interruptible? If so, what happens if the + ioctl is interrupted by a signal? Might it partially copy the + range? */ + struct file_clone_range range = { src_fd: source, src_offset: off, + src_length: length, dest_offset: off }; + if (ioctl (dest, FICLONERANGE, &range) == 0) + return true; +#endif + return false; +} + DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6, "fCopy file: \nGCopy %s to file: \np\nP", doc: /* Copy FILE to NEWNAME. Both args must be strings. @@ -1974,7 +1996,7 @@ permissions. */) record_unwind_protect_int (close_file_unwind, ofd); - off_t oldsize = 0, newsize = 0; + off_t oldsize = 0, newsize; if (already_exists) { @@ -1990,18 +2012,32 @@ permissions. */) immediate_quit = 1; QUIT; - while (true) - { - char buf[MAX_ALLOCA]; - ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); - if (n < 0) - report_file_error ("Read error", file); - if (n == 0) - break; - if (emacs_write_sig (ofd, buf, n) != n) - report_file_error ("Write error", newname); - newsize += n; - } + + off_t insize = st.st_size; + /* FIXME: is 1 GiB a good number? */ + off_t max_clone_chunk_size = 1 << 30; + off_t chunk_size = min (insize, max_clone_chunk_size); + + if (clone_file_range (ofd, ifd, 0, chunk_size)) + for (newsize = chunk_size; newsize < insize; newsize += chunk_size) + { + chunk_size = min (insize - newsize, max_clone_chunk_size); + if (! clone_file_range (ofd, ifd, newsize, chunk_size)) + report_file_error ("Clone error", file); + } + else + for (newsize = 0; ; newsize += chunk_size) + { + char buf[MAX_ALLOCA]; + ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); + if (n < 0) + report_file_error ("Read error", file); + if (n == 0) + break; + if (emacs_write_sig (ofd, buf, n) != n) + report_file_error ("Write error", newname); + chunk_size = n; + } /* Truncate any existing output file after writing the data. This is more likely to work than truncation before writing, if the -- 2.5.5 --------------030504080808070801020508-- From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.14678171494970 (code B ref 23904); Wed, 06 Jul 2016 15:00:02 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 14:59:09 +0000 Received: from localhost ([127.0.0.1]:39656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoI9-0001I6-7i for submit@debbugs.gnu.org; Wed, 06 Jul 2016 10:59:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoI7-0001Hi-KV for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 10:59:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKoI1-0002wy-OB for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 10:59:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKoHa-0002pm-Do; Wed, 06 Jul 2016 10:58:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4420 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bKoHW-0007zB-0j; Wed, 06 Jul 2016 10:58:30 -0400 Date: Wed, 06 Jul 2016 17:58:15 +0300 Message-Id: <83oa6an794.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <577CF00A.80707@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Jul 2016 13:48:26 +0200) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Paul Eggert > Date: Wed, 6 Jul 2016 13:48:26 +0200 > Cc: sbaugh@catern.com, Kieran Colford > > Revised patch attached. Basically untested, since I don't use any file > systems that support FIOCLONERANGE. The patch still has FIXMEs for what > happens if the FIOCLONERANGE ioctl is interrupted by a signal, and for a > good clone chunk size (the patch guesses 1 GiB). Thanks. However, I wonder: are we sure users will always want this unconditionally, completely out of their control? Does 'cp' from Coreutils do the same unconditionally, for example? From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 15:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.146781773412073 (code B ref 23904); Wed, 06 Jul 2016 15:09:02 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 15:08:54 +0000 Received: from localhost ([127.0.0.1]:39667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoRU-00038U-6A for submit@debbugs.gnu.org; Wed, 06 Jul 2016 11:08:53 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoRO-000382-LM for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 11:08:47 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1D36A161294; Wed, 6 Jul 2016 08:08:37 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id exLAURQ_X8nm; Wed, 6 Jul 2016 08:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5E4791614D0; Wed, 6 Jul 2016 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PXo1s_Oac0uJ; Wed, 6 Jul 2016 08:08:36 -0700 (PDT) Received: from [192.168.0.35] (89-159-79-138.rev.numericable.fr [89.159.79.138]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3A8D4161294; Wed, 6 Jul 2016 08:08:35 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> From: Paul Eggert Message-ID: <577D1EF1.5020401@cs.ucla.edu> Date: Wed, 6 Jul 2016 17:08:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <83oa6an794.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) On 07/06/2016 04:58 PM, Eli Zaretskii wrote: > are we sure users will always want this > unconditionally, completely out of their control? Does 'cp' from > Coreutils do the same unconditionally, for example? No, coreutils cp has an option. As I recall it was put in soon after the btrfs feature was added, and we were worried about bugs in btrfs. This was several years ago. We're thinking of making cloning the default in cp (on systems that support it) but haven't gotten around to it. We could add another optional argument to copy-file as well, if there's a significant need. I would omit such an option at first, though, as that's simpler. From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 15:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.146781882213712 (code B ref 23904); Wed, 06 Jul 2016 15:28:02 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 15:27:02 +0000 Received: from localhost ([127.0.0.1]:39680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoj3-0003Yv-Ll for submit@debbugs.gnu.org; Wed, 06 Jul 2016 11:27:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKoiy-0003Ya-M9 for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 11:26:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKoio-0002Ao-U9 for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 11:26:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKoiQ-000265-Gr; Wed, 06 Jul 2016 11:26:18 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4446 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bKoiO-0006e4-2T; Wed, 06 Jul 2016 11:26:16 -0400 Date: Wed, 06 Jul 2016 18:26:01 +0300 Message-Id: <83k2gyn5yu.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <577D1EF1.5020401@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Jul 2016 17:08:33 +0200) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: dmantipov@yandex.ru, 23904@debbugs.gnu.org, sbaugh@catern.com, > kieran@kcolford.com > From: Paul Eggert > Date: Wed, 6 Jul 2016 17:08:33 +0200 > > No, coreutils cp has an option. As I recall it was put in soon after the > btrfs feature was added, and we were worried about bugs in btrfs. This > was several years ago. We're thinking of making cloning the default in > cp (on systems that support it) but haven't gotten around to it. When 'cp' switches to using this by default, will it still have an option to disable it? If so, I would think it will be too bold for Emacs not provide such an option for users, even as opt-out. From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2016 17:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.146782636631795 (code B ref 23904); Wed, 06 Jul 2016 17:33:01 +0000 Received: (at 23904) by debbugs.gnu.org; 6 Jul 2016 17:32:46 +0000 Received: from localhost ([127.0.0.1]:39840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKqgo-0008Gl-Jm for submit@debbugs.gnu.org; Wed, 06 Jul 2016 13:32:46 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKqgn-0008GY-2a for 23904@debbugs.gnu.org; Wed, 06 Jul 2016 13:32:45 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2DFF0160CB5; Wed, 6 Jul 2016 10:32:39 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id x8093HLETwBV; Wed, 6 Jul 2016 10:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7BCF51614D4; Wed, 6 Jul 2016 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NvwJ4vPEtmFi; Wed, 6 Jul 2016 10:32:38 -0700 (PDT) Received: from [192.168.0.35] (89-159-79-138.rev.numericable.fr [89.159.79.138]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4429D160CB5; Wed, 6 Jul 2016 10:32:37 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> From: Paul Eggert Message-ID: <577D40AA.9060004@cs.ucla.edu> Date: Wed, 6 Jul 2016 19:32:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <83k2gyn5yu.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) On 07/06/2016 05:26 PM, Eli Zaretskii wrote: > When 'cp' switches to using this by default, will it still have an > option to disable it? Yes. It already has that option and we wouldn't remove it due to backward-compatibility concerns, at least, not for many years. The situation for Emacs is a bit different, as Emacs doesn't have the backward-compatibility issues. From unknown Tue Jun 17 01:47:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Paul Eggert Subject: bug#23904: closed (Re: bug#23904: Btrfs clone support in copy operations) Message-ID: References: <577C5588.3060608@cs.ucla.edu> X-Gnu-PR-Message: they-closed 23904 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 23904@debbugs.gnu.org Date: Sun, 11 Sep 2016 02:17:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1473560222-16069-1" This is a multi-part message in MIME format... ------------=_1473560222-16069-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #23904: Btrfs clone support in copy operations which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 23904@debbugs.gnu.org. --=20 23904: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D23904 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1473560222-16069-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 23904-done) by debbugs.gnu.org; 11 Sep 2016 02:16:49 +0000 Received: from localhost ([127.0.0.1]:55860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biuK8-0004Ah-Uv for submit@debbugs.gnu.org; Sat, 10 Sep 2016 22:16:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biuK6-000486-VX for 23904-done@debbugs.gnu.org; Sat, 10 Sep 2016 22:16:47 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3426F160972; Sat, 10 Sep 2016 19:16:41 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ks4EFEJz6BLs; Sat, 10 Sep 2016 19:16:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 92881160D51; Sat, 10 Sep 2016 19:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jhd6YY1HydA1; Sat, 10 Sep 2016 19:16:39 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5FCEA160972; Sat, 10 Sep 2016 19:16:39 -0700 (PDT) Subject: Re: bug#23904: Btrfs clone support in copy operations To: Eli Zaretskii References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sat, 10 Sep 2016 19:16:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <577D40AA.9060004@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------2C65B2C112D7FD54C9DF41CE" X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 23904-done Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) This is a multi-part message in MIME format. --------------2C65B2C112D7FD54C9DF41CE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I looked into this a bit more, and it appears that there's little point t= o=20 giving the user an option to clone or not clone when copying files, as th= e=20 cloning (or not cloning) can occur anyway. We plan to release a coreutils version soon and to change the default to = clone=20 after the release. For Emacs master the next release is far away, so ther= e is=20 plenty of time to try out the FICLONE performance improvement. I installe= d the=20 attached two patches and am marking this bug report as done. The second patch merely updates the documentation to discuss the issue; i= t is=20 logically independent of the first patch, since the issue can occur both = with=20 and without the first patch. --------------2C65B2C112D7FD54C9DF41CE Content-Type: text/x-diff; name="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" =46rom f9527cb5a5cdd05b2c98be089023b64ee9ee318b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 10 Sep 2016 12:51:27 -0700 Subject: [PATCH 1/2] copy-file now uses GNU/Linux file cloning =46rom a suggestion by Kieran Colford (see Bug#23904). * configure.ac: Check for linux/fs.h. * src/fileio.c [HAVE_LINUX_FS_H]: Include sys/ioctl.h and linux/fs.h. (clone_file): New function. (Fcopy_file): Use it. --- configure.ac | 1 + src/fileio.c | 33 +++++++++++++++++++++++++-------- 2 files changed, 26 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 9856228..82a672b 100644 --- a/configure.ac +++ b/configure.ac @@ -1638,6 +1638,7 @@ AC_DEFUN =20 dnl checks for header files AC_CHECK_HEADERS_ONCE( + linux/fs.h malloc.h sys/systeminfo.h sys/sysinfo.h diff --git a/src/fileio.c b/src/fileio.c index bf6bf62..b4316b3 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -52,6 +52,11 @@ along with GNU Emacs. If not, see . */ #include "region-cache.h" #include "frame.h" =20 +#ifdef HAVE_LINUX_FS_H +# include +# include +#endif + #ifdef WINDOWSNT #define NOMINMAX 1 #include @@ -1829,6 +1834,16 @@ barf_or_query_if_file_exists (Lisp_Object absname,= bool known_to_exist, } } =20 +/* Copy data to DEST from SOURCE if possible. Return true if OK. */ +static bool +clone_file (int dest, int source) +{ +#ifdef FICLONE + return ioctl (dest, FICLONE, source) =3D=3D 0; +#endif + return false; +} + DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6, "fCopy file: \nGCopy %s to file: \np\nP", doc: /* Copy FILE to NEWNAME. Both args must be strings. @@ -1975,7 +1990,7 @@ permissions. */) =20 record_unwind_protect_int (close_file_unwind, ofd); =20 - off_t oldsize =3D 0, newsize =3D 0; + off_t oldsize =3D 0, newsize; =20 if (already_exists) { @@ -1991,17 +2006,19 @@ permissions. */) =20 immediate_quit =3D 1; QUIT; - while (true) + + if (clone_file (ofd, ifd)) + newsize =3D st.st_size; + else { char buf[MAX_ALLOCA]; - ptrdiff_t n =3D emacs_read (ifd, buf, sizeof buf); + ptrdiff_t n; + for (newsize =3D 0; 0 < (n =3D emacs_read (ifd, buf, sizeof buf));= + newsize +=3D n) + if (emacs_write_sig (ofd, buf, n) !=3D n) + report_file_error ("Write error", newname); if (n < 0) report_file_error ("Read error", file); - if (n =3D=3D 0) - break; - if (emacs_write_sig (ofd, buf, n) !=3D n) - report_file_error ("Write error", newname); - newsize +=3D n; } =20 /* Truncate any existing output file after writing the data. This --=20 2.7.4 --------------2C65B2C112D7FD54C9DF41CE Content-Type: text/x-diff; name="0002-Document-file-synchronization-issues.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-Document-file-synchronization-issues.patch" =46rom 62f0eb5f8ce6a05288c0b7b7cf8ec3dc373583e4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 10 Sep 2016 19:12:21 -0700 Subject: [PATCH 2/2] Document file synchronization issues * doc/lispref/files.texi (Files and Storage): New section. --- doc/emacs/files.texi | 4 ++-- doc/lispref/backups.texi | 5 +++++ doc/lispref/files.texi | 25 +++++++++++++++++++++++++ 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi index f195a41..7bf4690 100644 --- a/doc/emacs/files.texi +++ b/doc/emacs/files.texi @@ -1554,8 +1554,8 @@ Misc File Ops =20 @findex copy-file @cindex copying files - @kbd{M-x copy-file} reads the file @var{old} and writes a new file -named @var{new} with the same contents. + @kbd{M-x copy-file} copies the contents of the file @var{old} to the +file @var{new}. =20 @findex copy-directory @kbd{M-x copy-directory} copies directories, similar to the diff --git a/doc/lispref/backups.texi b/doc/lispref/backups.texi index b9e6466..35a1865 100644 --- a/doc/lispref/backups.texi +++ b/doc/lispref/backups.texi @@ -41,6 +41,11 @@ Backup Files file gets a new name. You can delete old numbered backups when you don't want them any more, or Emacs can delete them automatically. =20 + For performance, the operating system may not write the backup +file's contents to secondary storage immediately, or may alias the +backup data with the original until one or the other is later +modified. @xref{Files and Storage}. + @menu * Making Backups:: How Emacs makes backup files, and when. * Rename or Copy:: Two alternatives: renaming the old file or copyin= g it. diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index 0aea1df..b912d7b 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -41,6 +41,7 @@ Files simultaneous editing by two people. * Information about Files:: Testing existence, accessibility, size of f= iles. * Changing Files:: Renaming files, changing permissions, etc. +* Files and Storage:: Surviving power and media failures * File Names:: Decomposing and expanding file names. * Contents of Directories:: Getting a list of the files in a directory.= * Create/Delete Dirs:: Creating and Deleting Directories. @@ -1496,6 +1497,10 @@ Changing Files system-dependent error message that describes the reason for the failure. =20 + For performance, the operating system may cache or alias changes +made by these functions instead of writing them immediately to +secondary storage. @xref{Files and Storage}. + In the functions that have an argument @var{newname}, if a file by the= name of @var{newname} already exists, the actions taken depend on the value of the argument @var{ok-if-already-exists}: @@ -1794,6 +1799,26 @@ Changing Files @var{filename}, @code{nil} otherwise. @end defun =20 +@node Files and Storage +@section Files and Secondary Storage +@cindex secondary storage + +After Emacs changes a file, there are two reasons the changes might +not survive later failures of power or media, both having to do with +efficiency. First, the operating system might alias written data with +data already stored elsewhere on secondary storage until one file or +the other is later modified; this will lose both files if the only +copy on secondary storage is lost due to media failure. Second, the +operating system might not write data to secondary storage +immediately, which will lose the data if power is lost. + +Although both sorts of failures can largely be avoided by a suitably +configured file system, such systems are typically more expensive or +less efficient. In more-typical systems, to survive media failure you +can copy the file to a different device, and to survive a power +failure you can invoke the @command{sync} utility (@pxref{sync +invocation,,, coreutils, The @sc{gnu} @code{Coreutils} Manual}). + @node File Names @section File Names @cindex file names --=20 2.7.4 --------------2C65B2C112D7FD54C9DF41CE-- ------------=_1473560222-16069-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 6 Jul 2016 00:49:38 +0000 Received: from localhost ([127.0.0.1]:38738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKb21-00052j-Sn for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKb1y-00052T-72 for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKb1r-0000Rt-Eq for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1r-0000Rm-BD for submit@debbugs.gnu.org; Tue, 05 Jul 2016 20:49:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1o-0000Kr-Lm for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKb1l-0000Qi-DD for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:24 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKb1l-0000Q9-4R for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 20:49:21 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B59131614C4; Tue, 5 Jul 2016 17:49:19 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SFeRXCk90mgA; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E03CE1614AD; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9qTC7WVSxn1m; Tue, 5 Jul 2016 17:49:17 -0700 (PDT) Received: from [192.168.0.35] (89-159-79-138.rev.numericable.fr [89.159.79.138]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1EDCB1613C2; Tue, 5 Jul 2016 17:49:16 -0700 (PDT) Subject: Re: Btrfs clone support in copy operations To: bug-gnu-emacs@gnu.org References: <1467745602.28158.17.camel@kcolford.com> From: Paul Eggert Message-ID: <577C5588.3060608@cs.ucla.edu> Date: Wed, 6 Jul 2016 02:49:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1467745602.28158.17.camel@kcolford.com> Content-Type: multipart/mixed; boundary="------------070407000101080704040409" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit Cc: sbaugh@catern.com, Kieran Colford X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) This is a multi-part message in MIME format. --------------070407000101080704040409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tags: patch The attached proposed patch to Emacs master builds on a suggestion by Kieran Colford. Kieran, can you please comment on its two FIXMEs? --------------070407000101080704040409 Content-Type: text/x-patch; name="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-copy-file-now-uses-GNU-Linux-file-cloning.patch" >From 4b2a532a87ec2a21afc205b83db4a779664ccd20 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 6 Jul 2016 02:42:58 +0200 Subject: [PATCH] copy-file now uses GNU/Linux file cloning >From a suggestion by Kieran Colford in: http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00191.html * configure.ac: Check for linux/fs.h. * src/fileio.c [HAVE_LINUX_FS_H]: Include sys/ioctl.h and linux/fs.h. (clone_file): New function. (Fcopy_file): Use it. --- configure.ac | 1 + src/fileio.c | 64 ++++++++++++++++++++++++++++++++++++++++++------------------ 2 files changed, 46 insertions(+), 19 deletions(-) diff --git a/configure.ac b/configure.ac index aaddfcd..1798fa3 100644 --- a/configure.ac +++ b/configure.ac @@ -1636,6 +1636,7 @@ AC_DEFUN dnl checks for header files AC_CHECK_HEADERS_ONCE( + linux/fs.h malloc.h sys/systeminfo.h sys/sysinfo.h diff --git a/src/fileio.c b/src/fileio.c index b1f9d3c..c2e3a18 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -52,6 +52,11 @@ along with GNU Emacs. If not, see . */ #include "region-cache.h" #include "frame.h" +#ifdef HAVE_LINUX_FS_H +# include +# include +#endif + #ifdef WINDOWSNT #define NOMINMAX 1 #include @@ -1828,6 +1833,24 @@ barf_or_query_if_file_exists (Lisp_Object absname, bool known_to_exist, } } +/* Copy all data to DEST from SOURCE if possible. Return true if OK. */ +static bool +clone_file (int dest, int source) +{ +#ifdef FICLONE + /* FIXME: Might this ioctl take a long time if the file is very + large? Is the ioctl interruptible? If so, what happens if the + ioctl is interrupted by a signal? Might it partially copy the + file? */ + /* FIXME: Does this ioctl truncate the output file to be the same + size as the input file, if the output file already exists and is + larger than the input file? */ + if (ioctl (dest, FICLONE, source) == 0) + return true; +#endif + return false; +} + DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6, "fCopy file: \nGCopy %s to file: \np\nP", doc: /* Copy FILE to NEWNAME. Both args must be strings. @@ -1988,28 +2011,31 @@ permissions. */) oldsize = out_st.st_size; } - immediate_quit = 1; - QUIT; - while (true) + if (! clone_file (ofd, ifd)) { - char buf[MAX_ALLOCA]; - ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); - if (n < 0) - report_file_error ("Read error", file); - if (n == 0) - break; - if (emacs_write_sig (ofd, buf, n) != n) - report_file_error ("Write error", newname); - newsize += n; - } + immediate_quit = 1; + QUIT; + while (true) + { + char buf[MAX_ALLOCA]; + ptrdiff_t n = emacs_read (ifd, buf, sizeof buf); + if (n < 0) + report_file_error ("Read error", file); + if (n == 0) + break; + if (emacs_write_sig (ofd, buf, n) != n) + report_file_error ("Write error", newname); + newsize += n; + } - /* Truncate any existing output file after writing the data. This - is more likely to work than truncation before writing, if the - file system is out of space or the user is over disk quota. */ - if (newsize < oldsize && ftruncate (ofd, newsize) != 0) - report_file_error ("Truncating output file", newname); + /* Truncate any existing output file after writing the data. This + is more likely to work than truncation before writing, if the + file system is out of space or the user is over disk quota. */ + if (newsize < oldsize && ftruncate (ofd, newsize) != 0) + report_file_error ("Truncating output file", newname); - immediate_quit = 0; + immediate_quit = 0; + } #ifndef MSDOS /* Preserve the original file permissions, and if requested, also its -- 2.5.5 --------------070407000101080704040409-- ------------=_1473560222-16069-1-- From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 15:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.14736075393942 (code B ref 23904); Sun, 11 Sep 2016 15:26:01 +0000 Received: (at 23904) by debbugs.gnu.org; 11 Sep 2016 15:25:39 +0000 Received: from localhost ([127.0.0.1]:56560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj6dS-00011R-Mq for submit@debbugs.gnu.org; Sun, 11 Sep 2016 11:25:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj6dR-00011E-3N for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 11:25:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj6dI-0002qc-VQ for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 11:25:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj6d3-0002kV-5s; Sun, 11 Sep 2016 11:25:09 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1135 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bj6d1-0007dZ-0W; Sun, 11 Sep 2016 11:25:07 -0400 Date: Sun, 11 Sep 2016 18:25:07 +0300 Message-Id: <83eg4qbgrw.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Sat, 10 Sep 2016 19:16:39 -0700) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.2 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) > Cc: dmantipov@yandex.ru, 23904-done@debbugs.gnu.org, sbaugh@catern.com, > kieran@kcolford.com > From: Paul Eggert > Date: Sat, 10 Sep 2016 19:16:39 -0700 > > > [1:text/plain Hide] > > I looked into this a bit more, and it appears that there's little point to > giving the user an option to clone or not clone when copying files, as the > cloning (or not cloning) can occur anyway. > > We plan to release a coreutils version soon and to change the default to clone > after the release. For Emacs master the next release is far away, so there is > plenty of time to try out the FICLONE performance improvement. I installed the > attached two patches and am marking this bug report as done. The first patch is fine with me. > The second patch merely updates the documentation to discuss the issue; it is > logically independent of the first patch, since the issue can occur both with > and without the first patch. I wonder why we need that text in the manual, it doesn't seem to provide any useful actionable info, just general description of an issue. From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 17:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.147361424714868 (code B ref 23904); Sun, 11 Sep 2016 17:18:01 +0000 Received: (at 23904) by debbugs.gnu.org; 11 Sep 2016 17:17:27 +0000 Received: from localhost ([127.0.0.1]:56673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj8Ni-0003rj-PE for submit@debbugs.gnu.org; Sun, 11 Sep 2016 13:17:27 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj8Nh-0003rX-8L for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 13:17:25 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 009E5160972; Sun, 11 Sep 2016 10:17:18 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YlXa-TYD36X1; Sun, 11 Sep 2016 10:17:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 49445161117; Sun, 11 Sep 2016 10:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MR60uLFCUMlp; Sun, 11 Sep 2016 10:17:18 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 274C8160972; Sun, 11 Sep 2016 10:17:18 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> <83eg4qbgrw.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 11 Sep 2016 10:17:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83eg4qbgrw.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) Eli Zaretskii wrote: > I wonder why we need that text in the manual, it doesn't seem to > provide any useful actionable info, just general description of an > issue. The intent is to say that Emacs does not guarantee that its changes to fi= les=20 might not survive power outages and the like. The new section briefly sug= gests=20 actions to take if this is of concern. Feel free to remove this stuff if = you=20 think it so obvious or out-of-scope that it should not be in the manual. From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 19:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.147362167032242 (code B ref 23904); Sun, 11 Sep 2016 19:22:02 +0000 Received: (at 23904) by debbugs.gnu.org; 11 Sep 2016 19:21:10 +0000 Received: from localhost ([127.0.0.1]:56776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAJP-0008Nu-5D for submit@debbugs.gnu.org; Sun, 11 Sep 2016 15:21:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAJM-0008N4-Rv for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 15:21:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjAJE-0007oD-MT for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 15:20:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjAJ1-0007jD-S5; Sun, 11 Sep 2016 15:20:43 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1359 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjAIx-0001h7-Qn; Sun, 11 Sep 2016 15:20:42 -0400 Date: Sun, 11 Sep 2016 22:20:22 +0300 Message-Id: <83sht69rbd.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Sun, 11 Sep 2016 10:17:17 -0700) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> <83eg4qbgrw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.2 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.2 (-------) > Cc: dmantipov@yandex.ru, 23904@debbugs.gnu.org, sbaugh@catern.com, > kieran@kcolford.com > From: Paul Eggert > Date: Sun, 11 Sep 2016 10:17:17 -0700 > > Eli Zaretskii wrote: > > I wonder why we need that text in the manual, it doesn't seem to > > provide any useful actionable info, just general description of an > > issue. > > The intent is to say that Emacs does not guarantee that its changes to files > might not survive power outages and the like. The new section briefly suggests > actions to take if this is of concern. Feel free to remove this stuff if you > think it so obvious or out-of-scope that it should not be in the manual. Does anyone else see this text as useful? I'm not going to remove it if someone might find it helpful. From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.147363389917927 (code B ref 23904); Sun, 11 Sep 2016 22:45:02 +0000 Received: (at 23904) by debbugs.gnu.org; 11 Sep 2016 22:44:59 +0000 Received: from localhost ([127.0.0.1]:56836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjDUh-0004f5-FW for submit@debbugs.gnu.org; Sun, 11 Sep 2016 18:44:59 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjDUf-0004es-Fn for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 18:44:58 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8E442161109; Sun, 11 Sep 2016 15:44:50 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5E3sIIzViRkI; Sun, 11 Sep 2016 15:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A42AB16111B; Sun, 11 Sep 2016 15:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id raIYnT1cUDyI; Sun, 11 Sep 2016 15:44:49 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 776B2161109; Sun, 11 Sep 2016 15:44:49 -0700 (PDT) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> <83eg4qbgrw.fsf@gnu.org> <83sht69rbd.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <1cdf90cd-192c-bf5c-cd63-f763594e1b8b@cs.ucla.edu> Date: Sun, 11 Sep 2016 15:44:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83sht69rbd.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------5A242941CA9276768C7E56B9" X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) This is a multi-part message in MIME format. --------------5A242941CA9276768C7E56B9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Come to think of it, the user manual already documents=20 write-region-inhibit-fsync, so it was a bit odd that the reference manual= was=20 silent about it. I installed the attached further patch to document=20 write-region-inhibit-fsync in the reference manual, and to help the refer= ence=20 manual avoid a dependency on the coreutils manual. --------------5A242941CA9276768C7E56B9 Content-Type: text/x-diff; name="0001-Remove-unnecessary-ref-to-coreutils-manual.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Remove-unnecessary-ref-to-coreutils-manual.patch" =46rom a2ce6f5da40e6b19e293588f2872a9fdb06b9bb1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 11 Sep 2016 15:09:04 -0700 Subject: [PATCH] Remove unnecessary ref to coreutils manual * doc/lispref/files.texi: Document write-region-inhibit-fsync. --- doc/lispref/files.texi | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index b912d7b..9a56d0a 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -661,6 +661,15 @@ Writing to Files files that the user does not need to know about. @end deffn =20 +@defvar write-region-inhibit-fsync +If this variable's value is @code{nil}, @code{write-region} uses the +@code{fsync} system call after writing a file. Although this slows +Emacs down, it lessens the risk of data loss after power failure. If +the value is @code{t}, Emacs does not use @code{fsync}. The default +value is @code{nil} when Emacs is interactive, and @code{t} when Emacs +runs in batch mode. @xref{Files and Storage}. +@end defvar + @defmac with-temp-file file body@dots{} @anchor{Definition of with-temp-file} The @code{with-temp-file} macro evaluates the @var{body} forms with a @@ -1812,12 +1821,15 @@ Files and Storage operating system might not write data to secondary storage immediately, which will lose the data if power is lost. =20 +@findex write-region +@vindex write-region-inhibit-fsync Although both sorts of failures can largely be avoided by a suitably configured file system, such systems are typically more expensive or less efficient. In more-typical systems, to survive media failure you can copy the file to a different device, and to survive a power -failure you can invoke the @command{sync} utility (@pxref{sync -invocation,,, coreutils, The @sc{gnu} @code{Coreutils} Manual}). +failure you can use the @code{write-region} function with the +@code{write-region-inhibit-fsync} variable set to @code{nil}. +@xref{Writing to Files}. =20 @node File Names @section File Names --=20 2.7.4 --------------5A242941CA9276768C7E56B9-- From unknown Tue Jun 17 01:47:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23904: Btrfs clone support in copy operations Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 02:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: sbaugh@catern.com, kieran@kcolford.com, dmantipov@yandex.ru, 23904@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23904-submit@debbugs.gnu.org id=B23904.14736477696191 (code B ref 23904); Mon, 12 Sep 2016 02:37:01 +0000 Received: (at 23904) by debbugs.gnu.org; 12 Sep 2016 02:36:09 +0000 Received: from localhost ([127.0.0.1]:56879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjH6L-0001bi-1r for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:36:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjH6I-0001bF-UH for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 22:36:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjH6A-0000FF-MS for 23904@debbugs.gnu.org; Sun, 11 Sep 2016 22:35:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjH60-0000BF-Eg; Sun, 11 Sep 2016 22:35:44 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1554 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjH5y-0007Eu-Kp; Sun, 11 Sep 2016 22:35:43 -0400 Date: Mon, 12 Sep 2016 05:35:44 +0300 Message-Id: <83oa3talq7.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <1cdf90cd-192c-bf5c-cd63-f763594e1b8b@cs.ucla.edu> (message from Paul Eggert on Sun, 11 Sep 2016 15:44:45 -0700) References: <1467745602.28158.17.camel@kcolford.com> <577C5588.3060608@cs.ucla.edu> <7d9c224b-e525-de33-426e-15bc328e7108@yandex.ru> <577CF00A.80707@cs.ucla.edu> <83oa6an794.fsf@gnu.org> <577D1EF1.5020401@cs.ucla.edu> <83k2gyn5yu.fsf@gnu.org> <577D40AA.9060004@cs.ucla.edu> <83eg4qbgrw.fsf@gnu.org> <83sht69rbd.fsf@gnu.org> <1cdf90cd-192c-bf5c-cd63-f763594e1b8b@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.2 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) > Cc: dmantipov@yandex.ru, 23904@debbugs.gnu.org, sbaugh@catern.com, > kieran@kcolford.com > From: Paul Eggert > Date: Sun, 11 Sep 2016 15:44:45 -0700 > > Come to think of it, the user manual already documents > write-region-inhibit-fsync, so it was a bit odd that the reference manual was > silent about it. I installed the attached further patch to document > write-region-inhibit-fsync in the reference manual, and to help the reference > manual avoid a dependency on the coreutils manual. Thanks, I think now that subsection makes more sense. But please remove the explicit @vindex entry, since @defvar already creates one, and in the correct place.