We can probably rule out
conv=sync to start with. It does something rather different, which I expect you do not want :-).
pad every input block with NULs to ibs-size; when used with
block or unblock, pad with spaces rather than NULs
oflag=direct does not sync automatically on its own.[*]
conv=fsync differs from
oflag=sync effectively syncs after each output block.
conv=fsync does one sync at the end.
The end result is the same, but the performance along the way is different :-).
oflag=sync could be significantly slower. You can mitigate this, by increasing the block size.
If device-specific caches are large, this will affect the progress reported e.g. by the
If you do not use
oflag=direct, then large amounts of writes can build up in the system page cache. This build-up will affect the progress you see. But also, Linux sometimes responds badly to the build-up, and degrades performance for all devices.
 "Apparently your hardware has hundreds of megabytes of cache... In my case, it is because the kernel is [actually running inside a virtual machine]". https://unix.stackexchange.com/a/420300/29483
 Why does a gunzip to dd pipeline slow down at the end?
 System lags when doing large R/W operations on external disks
[*] When writing directly to a block device node, Linux syncs the block device when it is closed (and is not open by any other program). I really do not recommend relying on this. However it explained something for me. Sometimes I see people who do not explicitly sync when writing to a block device, and it seems to work OK for them :-). See: Block device cache v.s. a filesystem