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
