GNU bug report logs -
#54586
dd conv options doc
Previous Next
Reported by: Karl Berry <karl <at> freefriends.org>
Date: Sat, 26 Mar 2022 20:30:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 54586 <at> debbugs.gnu.org.
--
54586: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54586
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
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.
[0001-dd-doc-improvement-Bug-54586.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
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.
This bug report was last modified 3 years and 14 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.