Re: writing iso file to usb stick with dd - garbled files - usb eject error?

[Nicolas George <george@nsup.org>]

Titus Newswanger (HE12025-08-02):
> Strangely, it did not display status updates like it used to until after it
> completed.

The rest has been explained, but not that. Let me.

First dd wrote all the data extremely fast. We can assume the input file
was recently downloaded and still in memory cache. And the output went
directly into memory cache for asynchronous writing. It all happened in
less than one second, so status=progress was not triggered even once.

That tell us your computer almost certainly has more than two gigaoctets
of memory, which nowadays is not that surprising.

Then dd closed its input file. Nothing much happened.

Then dd closed its output file. If it was a regular file, nothing much
would have happened. But this time it was a block device, and
furthermore a block device that nobody else kept open. In that case, the
kernel performs the equivalent of a fsync as part of the close: the
close returns only when the buffers have been written to the device.

Finally, dd printed its final statistics, taking the time for the close
into account, thus ruining the impressive speed of the reads and writes.

Note it is not a feature of dd, the same would have happened with cat or
any other writing program (I like pv to have a progress bar and
sometimes ETA estimate).

As Tomas pointed, with dd specifically you can use oflag=sync to have it
sync explicitly between each block, to get a better progress estimate.
Be sure to use a large block size or you will ruin performances.

Regards,

-- 
  Nicolas George