bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion: A No-write Option, e.g. --scrub.


From: Antonio Diaz Diaz
Subject: Re: Suggestion: A No-write Option, e.g. --scrub.
Date: Sat, 07 Mar 2020 00:01:24 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14

Ralph Corderoy wrote:
     $ strace -c tee <$f 2>&1 >/dev/null | sed 4q
     % time     seconds  usecs/call     calls    errors syscall
     ------ ----------- ----------- --------- --------- ----------------
      56.73    0.126982          33      3750           read
      43.23    0.096779          25      3743           write

25 µs/call? It seems that your hardware is very slow. I have tried the command above on my AMD Athlon64 and it is 38000 times faster (0.65 ns/call).

$ strace -c tee < enwik8 2>&1 > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 82.98    0.000039           0     12210           read
 17.02    0.000008           0     12208           write

Even my AMD K6-II 450 MHz from 1999 is almost one hundred times faster (0.28 µs/call).


The extra writes to /dev/null are adding 0.1 s and that's about 75% of
the time taken by all the read()s.

I guess this is because you are reading a file cached in RAM. Reading from a real USB pendrive in the K6 gives:

$ strace -c tee < binutils-2.32.tar.lz 2>&1 > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 98.77    0.056898          23      2494           read
  1.23    0.000708           0      2490           write


So it might be a measurable saving to avoid the write()s when scrubbing
1 TB, say.

On my Athlon64, ddrescue copies 1 TB from /dev/zero to /dev/null in 2m40s (6.25 GB/s), which makes the savings insignificant. When reading from a real device the savings are even more insignificant. Ddrescue spends much more time managing the mapfile than writing to /dev/null. (Note that the total read/write/seek time is itself an insignificant fraction of total run time):

$ strace -c ddrescue -f -s1TB /dev/zero /dev/null 2>&1 > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 91.86    0.215880           0  15258794           read
  5.16    0.012119           0  30517582           lseek
  2.98    0.007014           0  15259740           write


Best regards,
Antonio.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]