I use ddrescue to image failing disk to sparse files - often the files become highly fragmented (>50k fragments).
I suspect that sometimes the imaging speed degrades because of the fragmentation. Is there way to detect if the slowness is because of the read to the source disk or the write to the target file?
I'm assuming ddrescue is reading from one block device and writing to another. You can run iostat -xyh 10 to find out how much data is being read/written/discarded per second on each block device (number of reads/writes/discards as well as the amount of data read/written/discarded).
Example output from a laptop with one SSD:
$ iostat -xyh /dev/nvme0n1 10
Linux 5.4.0-26-generic (tux) 05/16/2020 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
16.3% 0.0% 34.7% 9.3% 0.0% 39.6%
r/s rkB/s rrqm/s %rrqm r_await rareq-sz Device
0.60 9.6k 0.00 0.0% 1.17 16.0k nvme0n1
w/s wkB/s wrqm/s %wrqm w_await wareq-sz Device
2422.60 294.7M 0.40 0.0% 11.41 124.5k nvme0n1
d/s dkB/s drqm/s %drqm d_await dareq-sz Device
0.00 0.0k 0.00 0.0% 0.00 0.0k nvme0n1
aqu-sz %util Device
23.25 34.3% nvme0n1
It's quite obvious from these numbers that I was heavily writing to my SSD while there were almost no read operations. You might also want to keep an eye on the iowait time related to reads ("r_await") and writes ("w_await").
Refer to the iostat man page for details.
ddrescue runs synchronously: read (lets say) 64k then write, so the rates are mostly equal (when I check with iotop) and I can't tell where the bottleneck is.