emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54586: closed (dd conv options doc)


From: GNU bug Tracking System
Subject: bug#54586: closed (dd conv options doc)
Date: Thu, 07 Jul 2022 04:48:02 +0000

Your message dated Wed, 6 Jul 2022 23:47:36 -0500
with message-id <a19b2a15-25eb-81f7-9590-16a33caace20@cs.ucla.edu>
and subject line Re: bug#54586: dd conv options doc
has caused the debbugs.gnu.org bug report #54586,
regarding dd conv options doc
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
54586: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54586
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: dd conv options doc Date: Sat, 26 Mar 2022 14:29:42 -0600
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.




--- End Message ---
--- Begin Message --- Subject: Re: bug#54586: dd conv options doc Date: Wed, 6 Jul 2022 23:47:36 -0500 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
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.

Attachment: 0001-dd-doc-improvement-Bug-54586.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]