Hi,
to...@tuxteam.de wrote:
> This is exactly why I'm always trying to "sell" the "oflag=sync" option of
> dd. You are going to write each block exactly once, then plop the medium
> out. So whithout, it'll take you 10 sec, with it'll take you as much. But
> it's more transparent with, because without, the OS is flushing cache in
> the background.
I let xorriso-dd-target use
bs=1M oflag=dsync
with the dd run which copies the ISO image. Not only to minimize the time
of the final sync command but also to get realistic numbers from
status=progress
which elsewise reports fantastic write speeds in the beginning and then
looks quite erratic when the kernel decides to write data to the USB stick
before buffering more of the data sent by dd.
What i experienced as puzzling in the documentation was the difference
between oflag=dsync and oflag=sync (not to be confused with conv=sync).
The info document of dd is more verbous than the man page but still not
really helpful in this aspect:
‘dsync’
Use synchronized I/O for data. For the output file, this
forces a physical write of output data on each write. For the
input file, this flag can matter when reading from a remote
file that has been written to synchronously by some other
process. Metadata (e.g., last-access and last-modified time)
is not necessarily synchronized.
‘sync’
Use synchronized I/O for both data and metadata.
I understand from
https://sources.debian.org/src/coreutils/9.4-3.1/src/dd.c
and
https://sources.debian.org/src/coreutils/9.4-3.1/lib/fd-reopen.c
that the difference is the one between open(2) flags O_SYNC and O_DSYNC.
man 2 open says:
To understand the difference between the two types of completion, con‐
sider two pieces of file metadata: the file last modification timestamp
(st_mtime) and the file length. All write operations will update the
last file modification timestamp, but only writes that add data to the
end of the file will change the file length. The last modification
timestamp is not needed to ensure that a read completes successfully,
but the file length is. Thus, O_DSYNC would only guarantee to flush
updates to the file length metadata (whereas O_SYNC would also always
flush the last modification timestamp metadata).
When writing to a device file, neither its length nor timestamp are of
importance for the resulting state of the USB stick. Length does not
change during writing and the timestamp vanishes with the device file
when the stick gets unplugged.
Nevertheless i add a standalone sync command to the last dd run of
xorriso-dd-target, just to care for any other remaining buffered data
e.g. from zeroizing the potential GPT backup header at the end of the
USB stick.
Michael Stone wrote:
> It's a waste of time
My experience with or without bs=1M oflag=dsync is like the sniffles:
They last seven days with a doctor and a week without.
Have a nice day :)
Thomas
