The behavior you're seeing is only
dd syncing the data on-disk after the operation. In order to optimize IO operations, Linux often reads data in larger chunks than requested (read-ahead) and delay writes so they can be combined (dirty cache). At the end of the operation, either
dd syncs the file on-disk or the kernel does it implicitly, and the process remains active until all the writes are finished.
If there is no other massive IO operations on the machine you should be able to estimate how much data there is left to write by looking at the "Dirty:" value in
/proc/meminfo - this is the total amount of data pending to be written to disk.
The amount of data the system can leave unwritten in memory at any one time can be controlled with the following sysctl tuning knobs. By default only the ratios are used. You can define the value in percent (ratio) or bytes.
You will find the official documentation for these parameters here:
iostat -d 1). Is
85.3 MB/sa realistic transfer rate for your USB stick and USB port? It looks as if
ddwaited for some buffer to flush, but I would expect it to exit anyway like in this question. Did it exit eventually?
ddbehaves as if it had
conv=fdatasyncoption enabled by default. I think if it didn't, it would exit like it happens in my previous link; then you would
syncand have to wait anyway. Try to force synchronous writing with
oflag=dsync. The overall average speed may be lower but the progress report should be accurate. Don't use very small
obsin this case because
ddwill sync the target device after every
cp- no need to use
dd if=/etc/fstab bs=32Mand it will read this small file just fine unless you're short of memory.