[Bug-ddrescue] Hanging ddrescue (infinite read operations)

[Linus Lüssing]

Hi!

First of all, I need to complain vehemently: GNU ddrescue works
too well :-). Now for the third time, it saved one of my neighbors
data! How should people learn to make backups if such an
awesome tool like ddrescue exists? :P

Just kidding ;) - you guys are awesome, GNU ddrescue is one of the
most valuable (and still too unknown) pieces of free software in my
opinion.


For this third use of ddrescue I wanted to share some
observations:

During this time I had a harddisk with a very peculiar
behaviour: It was a very optimistic disk, it would often try to
read indefinitely without throwing an error. Some details from
S.M.A.R.T.:

-----
Model Family:     Hitachi/HGST Travelstar 5K750
Device Model:     APPLE HDD HTS547550A9E384
Serial Number:    xxxxxxxx
LU WWN Device Id: 5 000cca 723c2c61e
Firmware Version: JE3AD70F
User Capacity:    500.107.862.016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 2.6, 3.0 Gb/s
-----

And I used it together with a SATA-to-USB adapter (lsusb says:
174c:1153 ASMedia Technology Inc. ASM2115 SATA 6Gb/s bridge)

During these hangs, the Ctrl-C would do nothing and even a SIGKILL
would not kill ddrescue. The SATA-to-USB adapter would continue
flashing its blue LED, seemingly still trying to read.

Question A): Would it be possible to reset the operation from
software somehow? A timeout in ddrescue? Or does this sound like a
hangup on an even lower level, the Linux kernel (I was using a
4.14.12 kernel on a 32bit ARM device, an Odroid U3) or maybe even
the disk and/or SATA-USB adapter so that power cycling the disk /
reconnecting the adapter is the only choice? I now spend quite
some hours with pulling and replugging the disk and restarting
ddrescue about once a minute.

Another observation: During the trimming and scraping phases (so
with the chunk size of 1 / 512B instead of 128x 512B chunks?) I
did not experience those tedious hangs anymore. Could it be a
firmware bug happening when requesting larger chunks?

Also, after pulling the USB cable, ddrescue unfroze and exited
with an error, as expected.

Regarding the unplugging I also noticed: Pulling without a
previous Ctrl+C seemed like a bad idea. This lead to ddrescue
adding many Megabytes of false negatives to the mapfile.

Question B): Would it be possible to prevent this?


For the Ctrl+C and then unplugging I noticed: Sometimes it exits
with an "interrupted by user", sometimes with a "input file/device
vanished". I couldn't figure out when one or the other might
happen, the result was seemingly random.

Also it seemed, that only for the latter exit case a bad cluster
was added to the mapfile? Which was the desirable result for me as
this was indeed a cluster hanging forever. For the "interrupted by
user" case it seemed that (usually?) no error was added to the
mapfile. Does that make sense?


Again, thanks for this great piece of software!

Regards, Linus

PS: In the end, with some manual replugging, ddrescue was able
to limit the unrecoverable read errors to 400KB at 100 areas
around the ~220GB region. Only 9 files/folders were
lost/damaged.

PPS: I was using ddrescue on a Debian unstable. So GNU ddrescue
version 1.22.