bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Ihor Radchenko]

Hi,

We are currently exploring performance of frequent file writes in Emacs.
This is important in org-persist library when we need to cache large
number of data pieces, writing them on disk.

It turns out that Emacs is pretty slow when writing hundreds of files:

(benchmark-run-compiled
    1000
  (with-temp-file "/tmp/test"
    (insert "test"))) ; => 4 sec

Mostly because of fsync:

(benchmark-run-compiled
    1000
  (let ((write-region-inhibit-fsync t))
    (with-temp-file "/tmp/test"
      (insert "test")))) ; => 0.15 sec

Timothy have found the following comment in src/fileio.c:

  /* fsync can be a significant performance hit.  Often it doesn't
     suffice to make the file-save operation survive a crash.  For
     batch scripts, which are typically part of larger shell commands
     that don't fsync other files, its effect on performance can be
     significant so its utility is particularly questionable.
     Hence, for now by default fsync is used only when interactive.

     For more on why fsync often fails to work on today's hardware, see:
     Zheng M et al. Understanding the robustness of SSDs under power fault.
     11th USENIX Conf. on File and Storage Technologies, 2013 (FAST '13), 271-84
     https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf

     For more on why fsync does not suffice even if it works properly, see:
     Roche X. Necessary step(s) to synchronize filename operations on disk.
     Austin Group Defect 672, 2013-03-19
     https://austingroupbugs.net/view.php?id=672  */
  write_region_inhibit_fsync = noninteractive;

Although fsync may provide some benefit on generic file systems, it does
not look like it is any useful in copy-on-write file systems.

I am wondering if Emacs could detect file system when writing the file
and disable fsync for FSes like BTRFS and other CoW file systems.

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2022-12-26 built on localhost
Repository revision: cc29fab3a66c59e77d0ff67c0f3e2e34ec80a03c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Gentoo Linux


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Eli Zaretskii]

> Cc: Timothy <orgmode@tec.tecosaur.net>
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Sun, 01 Jan 2023 18:51:59 +0000
> 
> We are currently exploring performance of frequent file writes in Emacs.
> This is important in org-persist library when we need to cache large
> number of data pieces, writing them on disk.
> 
> It turns out that Emacs is pretty slow when writing hundreds of files:
> 
> (benchmark-run-compiled
>     1000
>   (with-temp-file "/tmp/test"
>     (insert "test"))) ; => 4 sec
> 
> Mostly because of fsync:
> 
> (benchmark-run-compiled
>     1000
>   (let ((write-region-inhibit-fsync t))
>     (with-temp-file "/tmp/test"
>       (insert "test")))) ; => 0.15 sec
> 
> Timothy have found the following comment in src/fileio.c:
> 
>   /* fsync can be a significant performance hit.  Often it doesn't
>      suffice to make the file-save operation survive a crash.  For
>      batch scripts, which are typically part of larger shell commands
>      that don't fsync other files, its effect on performance can be
>      significant so its utility is particularly questionable.
>      Hence, for now by default fsync is used only when interactive.
> 
>      For more on why fsync often fails to work on today's hardware, see:
>      Zheng M et al. Understanding the robustness of SSDs under power fault.
>      11th USENIX Conf. on File and Storage Technologies, 2013 (FAST '13), 271-84
>      https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
> 
>      For more on why fsync does not suffice even if it works properly, see:
>      Roche X. Necessary step(s) to synchronize filename operations on disk.
>      Austin Group Defect 672, 2013-03-19
>      https://austingroupbugs.net/view.php?id=672  */
>   write_region_inhibit_fsync = noninteractive;
> 
> Although fsync may provide some benefit on generic file systems, it does
> not look like it is any useful in copy-on-write file systems.
> 
> I am wondering if Emacs could detect file system when writing the file
> and disable fsync for FSes like BTRFS and other CoW file systems.

Paul, any comments?

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On 2023-01-01 12:07, Eli Zaretskii wrote:

> Paul, any comments?

Sure, Emacs should do the reverse of what it's doing now. That is, Emacs 
should use fsync only in special situations, instead of avoiding it only 
in special situations. In the old days it may have made sense to use 
fsync, but nowadays most platforms don't need fsync for the sorts of 
things people use interactive Emacs.

For what it's worth I've had (setq write-region-inhibit-fsync t) in my 
init file for many years, without problems.

Proposed patch attached.

[-- Attachment #2: 0001-Improve-interactive-file-saving-performance.patch --]
[-- Type: text/x-patch, Size: 3355 bytes --]

From 55bf8954d181a74349d06a48e33ef84529fb7049 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 1 Jan 2023 14:05:04 -0800
Subject: [PATCH] Improve interactive file-saving performance

* src/fileio.c (init_fileio, syms_of_fileio):
Default write-region-inhibit-fsync to t (Bug#60474).
---
 doc/emacs/files.texi   | 3 +--
 doc/lispref/files.texi | 3 +--
 etc/NEWS               | 4 ++++
 src/fileio.c           | 6 +++---
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 6d66683161..5164339c66 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -815,8 +815,7 @@ Customize Save
 
   The @code{write-region-inhibit-fsync} variable controls whether
 Emacs invokes @code{fsync} after saving a file.  The variable's
-default value is @code{nil} when Emacs is interactive, and @code{t}
-when Emacs runs in batch mode (@pxref{Initial Options, Batch Mode}).
+default value is @code{t}.
 
   Emacs never uses @code{fsync} when writing auto-save files, as these
 files might lose data anyway.
diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi
index 707af6ee64..57784fb57f 100644
--- a/doc/lispref/files.texi
+++ b/doc/lispref/files.texi
@@ -695,8 +695,7 @@ Writing to Files
 @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}.
+value is @code{t}.  @xref{Files and Storage}.
 @end defvar
 
 @defmac with-temp-file file body@dots{}
diff --git a/etc/NEWS b/etc/NEWS
index eb68ce434b..1ab6822da3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -41,6 +41,10 @@ compositing manager, Emacs will now redisplay such a frame even though
 'frame-visible-' returns nil or 'icon' for it.  This can happen, for
 example, as part of preview for iconified frames.
 
++++
+** 'write-region-inhibit-fsync' now defaults to t in interactive mode,
+as it has in batch mode since Emacs 24.
+
 \f
 * Editing Changes in Emacs 30.1
 
diff --git a/src/fileio.c b/src/fileio.c
index 7fb7f5ddc5..bd4c8ec0c9 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -6351,7 +6351,7 @@ init_fileio (void)
      Roche X. Necessary step(s) to synchronize filename operations on disk.
      Austin Group Defect 672, 2013-03-19
      https://austingroupbugs.net/view.php?id=672  */
-  write_region_inhibit_fsync = noninteractive;
+  write_region_inhibit_fsync = true;
 }
 
 void
@@ -6610,8 +6610,8 @@ do (file-exists-p FILENAME) and FILENAME is handled by HANDLER, then
 	       doc: /* Non-nil means don't call fsync in `write-region'.
 This variable affects calls to `write-region' as well as save commands.
 Setting this to nil may avoid data loss if the system loses power or
-the operating system crashes.  By default, it is non-nil in batch mode.  */);
-  write_region_inhibit_fsync = 0; /* See also `init_fileio' above.  */
+the operating system crashes.  By default, it is non-nil.  */);
+  write_region_inhibit_fsync = true; /* See also `init_fileio' above.  */
 
   DEFVAR_BOOL ("delete-by-moving-to-trash", delete_by_moving_to_trash,
                doc: /* Specifies whether to use the system's trash can.
-- 
2.38.1

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Ihor Radchenko]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2023-01-01 12:07, Eli Zaretskii wrote:
>
>> Paul, any comments?
>
> Sure, Emacs should do the reverse of what it's doing now. That is, Emacs 
> should use fsync only in special situations, instead of avoiding it only 
> in special situations. In the old days it may have made sense to use 
> fsync, but nowadays most platforms don't need fsync for the sorts of 
> things people use interactive Emacs.

What about Emacs DOS port and the likes? May be there some gotchas about
specific file systems in non-standard OS?

Also, what would be the special situations you are talking about?

> diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
> index 6d66683161..5164339c66 100644
> --- a/doc/emacs/files.texi
> +++ b/doc/emacs/files.texi
> @@ -815,8 +815,7 @@ Customize Save
>  
>    The @code{write-region-inhibit-fsync} variable controls whether
>  Emacs invokes @code{fsync} after saving a file.  The variable's
> -default value is @code{nil} when Emacs is interactive, and @code{t}
> -when Emacs runs in batch mode (@pxref{Initial Options, Batch Mode}).
> +default value is @code{t}.
>  
>    Emacs never uses @code{fsync} when writing auto-save files, as these
>  files might lose data anyway.
> diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi
> index 707af6ee64..57784fb57f 100644
> --- a/doc/lispref/files.texi
> +++ b/doc/lispref/files.texi
> @@ -695,8 +695,7 @@ Writing to Files
>  @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}.
> +value is @code{t}.  @xref{Files and Storage}.
>  @end defvar

I think that the above pieces of the manuals are written under the
premise that fsync is executed by default. Merely changing the default
value makes the whole paragraph confusing.

> diff --git a/src/fileio.c b/src/fileio.c
> index 7fb7f5ddc5..bd4c8ec0c9 100644
> --- a/src/fileio.c
> +++ b/src/fileio.c
> @@ -6351,7 +6351,7 @@ init_fileio (void)
>       Roche X. Necessary step(s) to synchronize filename operations on disk.
>       Austin Group Defect 672, 2013-03-19
>       https://austingroupbugs.net/view.php?id=672  */
> -  write_region_inhibit_fsync = noninteractive;
> +  write_region_inhibit_fsync = true;
>  }

This change contradicts what the above comments states:

"     Hence, for now by default fsync is used only when interactive."

> @@ -6610,8 +6610,8 @@ do (file-exists-p FILENAME) and FILENAME is handled by HANDLER, then
>  	       doc: /* Non-nil means don't call fsync in `write-region'.
>  This variable affects calls to `write-region' as well as save commands.
>  Setting this to nil may avoid data loss if the system loses power or
> -the operating system crashes.  By default, it is non-nil in batch mode.  */);
> -  write_region_inhibit_fsync = 0; /* See also `init_fileio' above.  */
> +the operating system crashes.  By default, it is non-nil.  */);
> +  write_region_inhibit_fsync = true; /* See also `init_fileio' above.  */

Will this `init_fileio' also appear in Elisp docstring?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 60474@debbugs.gnu.org,
>  orgmode@tec.tecosaur.net
> Date: Mon, 02 Jan 2023 05:54:11 +0000
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> > On 2023-01-01 12:07, Eli Zaretskii wrote:
> >
> >> Paul, any comments?
> >
> > Sure, Emacs should do the reverse of what it's doing now. That is, Emacs 
> > should use fsync only in special situations, instead of avoiding it only 
> > in special situations. In the old days it may have made sense to use 
> > fsync, but nowadays most platforms don't need fsync for the sorts of 
> > things people use interactive Emacs.
> 
> What about Emacs DOS port and the likes? May be there some gotchas about
> specific file systems in non-standard OS?

Those systems have much more conservative filesystems, so they rarely
need fsync in the "usual" cases.

> Also, what would be the special situations you are talking about?

Right, that's my question as well.  I presume when writing some
precious data, or maybe some transaction-like I/O.

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Eli Zaretskii]

> Date: Sun, 1 Jan 2023 19:21:20 -0800
> Cc: 60474@debbugs.gnu.org, orgmode@tec.tecosaur.net,
>  Ihor Radchenko <yantar92@posteo.net>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > Paul, any comments?
> 
> Sure, Emacs should do the reverse of what it's doing now. That is, Emacs 
> should use fsync only in special situations, instead of avoiding it only 
> in special situations. In the old days it may have made sense to use 
> fsync, but nowadays most platforms don't need fsync for the sorts of 
> things people use interactive Emacs.
> 
> For what it's worth I've had (setq write-region-inhibit-fsync t) in my 
> init file for many years, without problems.
> 
> Proposed patch attached.

Thanks, this is okay for master, but could you perhaps add a sentence,
in the manual and in NEWS, about the exceptional situations when this
variable should be reset to nil?  I think we should say something,
otherwise the need for the variable is questionable.

bug#60474: 30.0.50; `write-region-inhibit-fsync' and copy-on-write file systems

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On 2023-01-02 04:12, Eli Zaretskii wrote:
> Thanks, this is okay for master, but could you perhaps add a sentence,
> in the manual and in NEWS, about the exceptional situations when this
> variable should be reset to nil?  I think we should say something,
> otherwise the need for the variable is questionable.

I gave that a shot and installed the attached patch to master. This 
patch also removes a now-duplicate assignment to 
write_region_inhibit_fsync in init_fileio. Closing the bug report.

While doing this I noticed that the only place 
write-region-inhibit-fsync is let-bound to nil in Emacs's own code is in 
lisp/emacs-lisp/multisession.el, due to commit 
ccb602836426f1fc2e43fa3506427744668f24c6 dated 2021-12-17 which I 
hypothesize is due to MS-Windows needing it when multiple processes are 
accessing the same file in a transaction-like application. So the 
attached patch adds some wording to that effect. Please feel free to 
improve it. I suppose for similar reasons it may also be helpful in 
GNU/Linux with transaction-like Emacs apps on networked file systems; I 
haven't checked this, though, and anyway once you're on a network this 
sort of thing is dubious anyway.

[-- Attachment #2: 0001-Improve-interactive-file-saving-performance.patch --]
[-- Type: text/x-patch, Size: 8121 bytes --]

From 2ee6012b3faaf12710ec63626795148caeef0f6a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 2 Jan 2023 10:00:41 -0800
Subject: [PATCH] Improve interactive file-saving performance

* src/fileio.c (init_fileio):
No longer any need to set write-region-inhibit-fsync here.
(syms_of_fileio): Default write-region-inhibit-fsync to t (Bug#60474).
---
 doc/emacs/files.texi   | 13 ++++++-------
 doc/lispref/files.texi | 27 ++++++++++++++++++---------
 etc/NEWS               |  4 ++++
 src/fileio.c           | 37 ++++++++++++++++---------------------
 4 files changed, 44 insertions(+), 37 deletions(-)

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 6d666831612..6a9103d3a09 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -801,22 +801,21 @@ Customize Save
 @vindex write-region-inhibit-fsync
   Normally, when a program writes a file, the operating system briefly
 caches the file's data in main memory before committing the data to
-disk.  This can greatly improve performance; for example, when running
-on laptops, it can avoid a disk spin-up each time a file is written.
-However, it risks data loss if the operating system crashes before
-committing the cache to disk.
+secondary storage.  Although this can greatly improve performance, it
+risks data loss if the system loses power before committing the cache,
+and on some platforms other processes might not immediately notice the
+file's change.
 
   To lessen this risk, Emacs can invoke the @code{fsync} system call
 after saving a file.  Using @code{fsync} does not eliminate the risk
-of data loss, partly because many systems do not implement
+of data loss or slow notification, partly because many systems do not support
 @code{fsync} properly, and partly because Emacs's file-saving
 procedure typically relies also on directory updates that might not
 survive a crash even if @code{fsync} works properly.
 
   The @code{write-region-inhibit-fsync} variable controls whether
 Emacs invokes @code{fsync} after saving a file.  The variable's
-default value is @code{nil} when Emacs is interactive, and @code{t}
-when Emacs runs in batch mode (@pxref{Initial Options, Batch Mode}).
+default value is @code{t}.
 
   Emacs never uses @code{fsync} when writing auto-save files, as these
 files might lose data anyway.
diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi
index 707af6ee64c..91643530f7f 100644
--- a/doc/lispref/files.texi
+++ b/doc/lispref/files.texi
@@ -692,11 +692,9 @@ Writing to Files
 
 @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}.
+@code{fsync} system call after writing a file.  If the value is
+@code{t}, Emacs does not use @code{fsync}.  The default value is
+@code{t}.  @xref{Files and Storage}.
 @end defvar
 
 @defmac with-temp-file file body@dots{}
@@ -2038,17 +2036,28 @@ Files and Storage
 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.
+immediately, which will lose the data if power is lost
+or if there is a media failure.
 
 @findex write-region
 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
+configured system, such systems are typically more expensive or
+less efficient.  In lower-end systems, to survive media failure you
 can copy the file to a different device, and to survive a power
-failure you can use the @code{write-region} function with the
+failure (or be immediately notified of a media failure) you can use
+the @code{write-region} function with the
 @code{write-region-inhibit-fsync} variable set to @code{nil}.
+Although this variable is ordinarily @code{t} because that can
+significantly improve performance, it may make sense to temporarily
+bind it to @code{nil} if using Emacs to implement database-like
+transactions that survive power failure on lower-end systems.
 @xref{Writing to Files}.
 
+On some platforms when Emacs changes a file other processes might not
+be notified of the change immediately.  Setting
+@code{write-region-inhibit-fsync} to @code{nil} may improve
+notification speed in this case, though there are no guarantees.
+
 @node File Names
 @section File Names
 @cindex file names
diff --git a/etc/NEWS b/etc/NEWS
index eb68ce434b3..1ab6822da3f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -41,6 +41,10 @@ compositing manager, Emacs will now redisplay such a frame even though
 'frame-visible-' returns nil or 'icon' for it.  This can happen, for
 example, as part of preview for iconified frames.
 
++++
+** 'write-region-inhibit-fsync' now defaults to t in interactive mode,
+as it has in batch mode since Emacs 24.
+
 \f
 * Editing Changes in Emacs 30.1
 
diff --git a/src/fileio.c b/src/fileio.c
index 7fb7f5ddc5e..c672e0f7baf 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -6334,24 +6334,6 @@ init_fileio (void)
   umask (realmask);
 
   valid_timestamp_file_system = 0;
-
-  /* fsync can be a significant performance hit.  Often it doesn't
-     suffice to make the file-save operation survive a crash.  For
-     batch scripts, which are typically part of larger shell commands
-     that don't fsync other files, its effect on performance can be
-     significant so its utility is particularly questionable.
-     Hence, for now by default fsync is used only when interactive.
-
-     For more on why fsync often fails to work on today's hardware, see:
-     Zheng M et al. Understanding the robustness of SSDs under power fault.
-     11th USENIX Conf. on File and Storage Technologies, 2013 (FAST '13), 271-84
-     https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
-
-     For more on why fsync does not suffice even if it works properly, see:
-     Roche X. Necessary step(s) to synchronize filename operations on disk.
-     Austin Group Defect 672, 2013-03-19
-     https://austingroupbugs.net/view.php?id=672  */
-  write_region_inhibit_fsync = noninteractive;
 }
 
 void
@@ -6609,9 +6591,22 @@ do (file-exists-p FILENAME) and FILENAME is handled by HANDLER, then
   DEFVAR_BOOL ("write-region-inhibit-fsync", write_region_inhibit_fsync,
 	       doc: /* Non-nil means don't call fsync in `write-region'.
 This variable affects calls to `write-region' as well as save commands.
-Setting this to nil may avoid data loss if the system loses power or
-the operating system crashes.  By default, it is non-nil in batch mode.  */);
-  write_region_inhibit_fsync = 0; /* See also `init_fileio' above.  */
+By default, it is non-nil.
+
+Although setting this to nil may avoid data loss if the system loses power,
+it can be a significant performance hit in the usual case, and it doesn't
+necessarily cause file-save operations to actually survive a crash.  */);
+
+  /* For more on why fsync often fails to work on today's hardware, see:
+     Zheng M et al. Understanding the robustness of SSDs under power fault.
+     11th USENIX Conf. on File and Storage Technologies, 2013 (FAST '13), 271-84
+     https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
+
+     For more on why fsync does not suffice even if it works properly, see:
+     Roche X. Necessary step(s) to synchronize filename operations on disk.
+     Austin Group Defect 672, 2013-03-19
+     https://austingroupbugs.net/view.php?id=672  */
+  write_region_inhibit_fsync = true;
 
   DEFVAR_BOOL ("delete-by-moving-to-trash", delete_by_moving_to_trash,
                doc: /* Specifies whether to use the system's trash can.
-- 
2.37.2