Subject: bug#54586: closed (Re: bug#54586: dd conv options doc)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 07 Jul 2022 04:48:02 +0000

Your bug report

#54586: dd conv options doc

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
54586: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54586
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#54586: dd conv options doc
From: Paul Eggert <[email-masked]>
To: Karl Berry <[email-masked]>
Cc: [email-masked]
Date: Wed, 6 Jul 2022 23:47:36 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

On 3/26/22 15:29, Karl Berry wrote:
> why would I want data to be synced and not metadata?

Performance, in apps that don't care about the metadata. Admittedly for 
dd the use case is rare; it's mostly present so that dd exports all the 
open flags to the user.

I installed the attached to try to document this better.
From 1efce5663554619db34d2722be7d6e5a14404065 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Wed, 6 Jul 2022 23:42:19 -0500
Subject: [PATCH] dd: doc improvement (Bug#54586)

* doc/coreutils.texi (dd invocation): Explain
fdatasync and fsync better.
---
 doc/coreutils.texi | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 7bca37b71..e0c87d1ad 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9466,7 +9466,13 @@ Continue after read errors.
 @cindex synchronized data writes, before finishing
 Synchronize output data just before finishing,
 even if there were write errors.
-This forces a physical write of output data.
+This forces a physical write of output data,
+so that even if power is lost the output data will be preserved.
+If neither this nor @samp{fsync} are specified, output is treated as
+usual with file systems, i.e., output data and metadata may be cached
+in primary memory for some time before the operating system physically
+writes it, and thus output data and metadata may be lost if power is lost.
+@xref{sync invocation}.
 This conversion is a GNU extension to POSIX.
 
 @item fsync
@@ -9474,7 +9480,10 @@ This conversion is a GNU extension to POSIX.
 @cindex synchronized data and metadata writes, before finishing
 Synchronize output data and metadata just before finishing,
 even if there were write errors.
-This forces a physical write of output data and metadata.
+This acts like @samp{fdatasync} except it also preserves output metadata,
+such as the last-modified time of the output file; for this reason it
+may be a bit slower than @samp{fdatasync} although the performance
+difference is typically insignificant for @command{dd}.
 This conversion is a GNU extension to POSIX.
 
 @end table
-- 
2.36.1

Subject: dd conv options doc
From: Karl Berry <[email-masked]>
To: [email-masked]
Date: Sat, 26 Mar 2022 14:29:42 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

The dd Texinfo doc says, for the conv= option
(https://gnu.org/s/coreutils/manual/html_node/dd-invocation.html)

     'fdatasync'
          Synchronize output data just before finishing.  This forces a
          physical write of output data.

     'fsync'
          Synchronize output data and metadata just before finishing.
          This forces a physical write of output data and metadata.

Weirdly, these descriptions are inducing quite a bit of FUD in me.

Why would I ever want the writes to be incomplete after running dd?
Seems like that is dd's whole purpose.

Well, I suppose it is too late to make such a radical change as forcing
a final sync. In which case I suggest adding another sentence along the
lines of "If these options are not specified, the data will be
physically written when the system schedules the syncs, ordinarily every
few seconds" (correct?). "You can also manually sync the output
filesystem yourself afterwards (xref sync)." Otherwise it feels
uncertain when or whether the data will be physically written, or how to
look into it further.

As for "metadata", what does dd have to do with metadata?  My wild guess
is that this is referring to filesystem metadata, not anything about dd
specifically. Whatever the case, I suggest adding a word or two to the
doc to give a clue.

Further, why would I want data to be synced and not metadata? Seems like
fdatasync and fsync should both do both; or at least document that
normally they'd be used together. Or, if there is a real-life case where
a user would want one and not the other, how about documenting that? My
imagination is failing me, but presumably these seemingly-undesirable
options were invented for a reason.

BTW, I came across these options on a random page discussing dumping a
.iso to a USB drive; the example was
  dd if=foo.iso of=/dev/sde conv=fdatasync
.. seems now like fsync should also have been given, for certainty.
--thanks, karl.