On 9/3/22 08:46, ppr wrote:
Le 01/09/2022 à 00:24, David Wright a écrit :
-R --reverse will start an attempt from the end of the disk, and if
you're extremely lucky, it might copy most of the remaining 960-odd GB
of data. OTOH it might only confirm that the disk is closer to meeting
its maker than it was when you started the rescue.
Thank you all for yours anwsers.
Following the suggestion of Cindy I rebooted the computer to see if
session's reboot freshness affects transfer. It did not in my case.
Transfert rate is very slow but ddrescue make some progress. After 5
days and one interruption (for rebooting), here is the current status:
---
# ddrescue -n /dev/sdb
/media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/image_HDD1.img
/media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/recup.log
GNU ddrescue 1.23
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 33992 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0
Current status
ipos: 72645 MB, non-trimmed: 26050 kB, current rate: 1638 B/s
opos: 72645 MB, non-scraped: 0 B, average rate: 55829 B/s
non-tried: 951012 MB, bad-sector: 0 B, error rate: 0 B/s
rescued: 49165 MB, bad areas: 0, run time: 3d 3h 29m
pct rescued: 4.91%, read errors: 490, remaining time: 5382d 14h
time since last successful read: 0s
Copying non-tried blocks... Pass 1 (forwards)
---
I am considering using -R option (as suggested by David Wright) to see
if ddrescue can have better transfert rate starting from the other side
of the HDD. My concern is whether or not ddrescue can resume a job
started, stopped, and relaunched with -R option added. ddrescue's manual
says only:
--reverse
Reverse the direction of all passes (copying, trimming, scraping,
and retrying). Every pass that is normally run forwards will now be run
backwards, and vice versa. '--reverse' does not modify the size of the
blocks copied during each phase, just the order in which they are tried.
If I stop ddrescue and add -R option, would the mapfile be able to
handle this (ddrescue started from the beginning and the end the the
drive)?
I also add some information related to other answers:
- The destination HDD is an external USB3 one. It is a physical RAID 1
with two 8To HDD 7200rpm. The commercial name is Lacie 2big raid. The
fact is image is growing and the speed seems to vary (even if never
fast) lets me think it is perhaps the HDD condition which is the cause
of the slow transfer rate.
- I commented out the failing HDD in /etc/fstab and disable
smartmontools tests for this drive. I did not try to mount the HDD.
Cheers.
ppr
I assume you are not seeing any problems with the destination drive (via
dmesg(1), /var/log/messages, etc.)?
Interpreting the ddrescue(1) output:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue
At 7200 RPM, ddrescue(1) should be reading 120 blocks per second. At
512 bytes per block, that is 61,440 bytes per second. I interpret the
"current rate: 1638 B/s" and "error rate: 0 B/s" statistics to mean that
the drive read 3 blocks and returned 0 errors in the second prior to the
displayed output. So, the drive took an average of 40 internal reads
for each of those 3 blocks returned to ddrescue(1) (via the kernel).
While it is good that the drive is returning data, reading each block 40
times scares me. You want ddrescue to read and return the good blocks
once each, and then fight the bad blocks.
Looking at the command line options:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue
I would interrupt (Ctrl+C) the current run and re-invoke ddrescue(1)
with the following options:
-a 30720
-d
-R
-T 10
I would not use "-K" option. I expect the GNU project carefully tuned
the initial and maximum skip size parameters. But, I do not know for
what size disk(s); yours is 1 TB. I would STFW for specific advice
before adjusting those parameters.
I would not use the "-n" option. The scrape phase is part of the design
of ddrescue; I would keep it.
The timeout option "-T 10" might stop ddrescue if it gets stuck when you
are not paying attention. If this happens, you can rethink the options
when restarting.
"--delay-slow=3", "--pause-on-error=3", and "--reset-slow=3" might be
useful for tuning "-a".
The "-i" option might be useful when restarting ddrescue. Leave it off
the first time you try "-R".
I sometimes watch disk I/O with nmon(1). But, the direct access "-d"
option might prevent nmon(1) from seeing disk I/O.
The verbose "-v" might be worth a try.
David
