Re: Usage: "debian ... amd64-netinst.iso"

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

tomas@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