My bad, I didnt include the ddrescue version. I have encountered this issue in version 1.23, and version 1.26 $ sudo ddrescue --version GNU ddrescue 1.26 Copyright (C) 2022 Antonio Diaz Diaz. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
On Tue, Jan 10, 2023 at 2:43 PM Eric Lovejoy <blic...@gmail.com> wrote: > So then you get impossibly fast write times, and boot disks that dont > work, because they arent actually complete, if the user removes the disk > when ddrescue reports that the operation is complete. > > $ sudo ddrescue --force bodhi-6.0.0-64.iso /dev/sdb > GNU ddrescue 1.23 > Press Ctrl-C to interrupt > ipos: 872349 kB, non-trimmed: 0 B, current rate: 727 MB/s > opos: 872349 kB, non-scraped: 0 B, average rate: 436 MB/s > non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s > rescued: 872415 kB, bad areas: 0, run time: 1s > pct rescued: 100.00%, read errors: 0, remaining time: n/a > time since last successful read: n/a > Finished > > > Shown here, a 1 second run time, for a 700MB file to USB. But I already > know this is impossible on my hardware. I'm just a dumb construction > worker, but if i had to guess, ddrescue is listening to userspace > libraries, rather than kernel signal processes. > > Here iostat reports: > iostat -d > Linux 5.15.0-56-generic (i) 01/10/2023 _x86_64_ (12 CPU) > > Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read > kB_wrtn kB_dscd > loop0 0.01 0.09 0.00 0.00 1133 > 0 0 > loop1 0.01 0.09 0.00 0.00 1133 > 0 0 > loop2 0.00 0.03 0.00 0.00 363 > 0 0 > loop3 0.01 0.09 0.00 0.00 1090 > 0 0 > loop4 0.01 0.04 0.00 0.00 439 > 0 0 > loop5 0.01 0.04 0.00 0.00 438 > 0 0 > sda 47.56 465.18 313.64 0.00 5574816 > 3758761 0 > sdb 0.47 0.16 36.52 0.00 1932 > 437704 0 > > It appears from iostat, that the disk sdb is still being written, despite > ddrescue reporting completion. > >