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. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
