Re: [Bug-ddrescue] ddrescue errors: maybe yes, maybe no

[Antonio Diaz Diaz]

Hello.

Kevin Hubbard wrote:
> I have upgraded ddrescue from 1.17 to 1.18-pre7 - although Icould not find a 
> Mac OS X binary, I managed to download thesource package, along with lzip, then 
> Configure/Make (I alreadyhad Xcode 3.2.6 installed (the latest for Snow Leopard 
> 10.6.8).

AFAIK, prereleases are not packaged but mainly tested by the brave 
audience of this list. :-)


> This newest level gives me the Rates and Reads option support,which is an 
> improvement on using just the Log file to determinewhat blocks are failing.

Glad to know that you find the new options useful.

BTW, would anybody here find useful that ddrescue could produce 
compressed logs of rates and reads? I think they may become pretty large 
(specially the reads log).


> 1) Direct Disk Access
> Tried -d and got error message "Direct disc access not available"

I think direct access does not work on Macs because they use a different 
way of activating it than linux. But it seems that raw devices work well 
there.

> Can you (re)write this patch ? Funding available on request ...

I almost never implement OS or device dependent features because they 
increase the complexity debt[1] and I can't test them. (They may become 
obsolete or broken without me noticing it).

[1]http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider
"Among the most dangerously unconsidered costs is what I've been calling 
complexity cost. Complexity cost is the debt you accrue by complicating 
features or technology in order to solve problems. An application that 
does twenty things is more difficult to refactor than an application 
that does one thing, so changes to its code will take longer. Sometimes 
complexity is a necessary cost, but only organizations that fully 
internalize the concept can hope to prevent runaway spending in this area."


> 2) Some testing /dev/disk vs. /dev/rdisk - Yes, rdisk is faster.
> Using Read Block size of 081920 bytes to copy first 22574MB,which does not 
> include the sectors in error, ie. no trimming.
> -v -n -b 4096 -c 20 -i 0x00 -o 0x00 -s 0x5418C0000 /dev/rdisk1s2result: 
> 8m28.617s
> -v -n -b 512 -c 160 -i 0x00 -o 0x00 -s 0x5418C0000 /dev/rdisk1s2result: 
> 8m28.851s
> -v -n -b 4096 -c 20 -i 0x00 -o 0x00 -s 0x5418C0000 /dev/disk1s2result: 
> 13m27.563s
> -v -n -b 512 -c 160 -i 0x00 -o 0x00 -s 0x5418C0000 /dev/disk1s2result: 
> 13m28.506s
> Note, I like that I can use input values denoted in hex. I couldnot find it 
> documented yes or no, so I tried it. Much easier.

I'll document in the manual that hex (and octal) can be used. Thanks.


> 3) Using the -i and -o options can be problematic
> Since my disk errors start at approx. 22574MB for 2000MB, I thoughtI'd get 
> clever and copy starting at 22572MB for 6000MB, using
> -i 0x541740000 -o 0x541740000 -s 0x5C0000

Using the -o option is not recommended unless you want a value different 
from the one of -i.


> However, although the copy completes quickly (3 errors, trim OK)and ddrescue says 
> "Finished", it isn't. Rather, the bash sessionis still active, with CPU 
> consumed by the kernel-task and ddrescuesustaining a 60 MB/sec write to disk, presumably 
> to fill theDMG file from 0x00 to 0x541740000. This takes about 7 minutes, andif you try 
> to cancel it before reaching normal end-of-job, thenthe system gets rather upset - it 
> cannot be shutdown or restarted,just powered off.

Maybe your destination filesystem does not support sparse files?


> To avoid the problem, I used
> -i 0x541740000 -o 0x00 -s 0x5C0000

If you are not interested in the data, you may use /dev/null as outfile.


> 4) Using the same disk/partition for input and output.
> I did this accidentally after being forced to power off/on, and theBSD name for 
> the input disk changed to match that now assigned tomy output disk. Pressing 
> the recall key in my Terminal bash sessionbrought back the previous ddrescue 
> command - it started to run andwas carrying on nicely until I noticed the 
> read/write light on theinput disk was not flashing. Also, the read/write lights 
> on the outputdisk (another RAID-1 array) were behaving rather oddly.
> ddrescue should flag this as an error.

Ddrescue does flag this as an error. But of course it allows the copy of 
a file or partition to another file or partition on the same disk.


> 5) Output disk/partition not large enough to hold input disk/partition.
> Again, I did this accidentally when I first invoked ddrescue, forgettingit runs 
> block-level, not file-level. The input partition is 1500000MB with348000MB in 
> use, so I choose a spare output partition 500000MB in size.But this is a 
> mistake to make just once.
> ddrescue should flag this as an error.

Try --preallocate. Verifying the free space on disk is tricky because 
you may want to copy just part of the input file.


> Suggestions to assist with problem determination:
> 1) Add Start and End timestamps as comments in all log files.
> 2) Add Created By and Command Line as comments in Read and Rates files,same as 
> that done in the Log file.

Good ideas. I'll implement them ASAP.


> 1) How can I get ddrescue to stop after First Step: Copying, and thenat some 
> later point, restart and continue with the remaining Steps ?
> It was this that prompted me to upgrade from 1.17 to 1.18-pre7, so Icould use 
> the Reads file to search for errors. Otherwise, at least in mycase, the Second 
> Step: Trimming, makes any read errors disappear outof the Log file.

Use --no-trim.

> ddrescue is excellent and easy-to-use for recovering data, but not somuch for 
> identifying bad sectors. In my case, I have found the locationsof 3 blocks, 
> 81920 in size, but am still clueless as to which of thesectors contained 
> therein are at fault. If I set block = sector, then noerrors are encountered, 
> ie. I do my own trimming.
> As I mentioned in my previous note, none of my other disk tools can findthen 
> either, at least in read-only mode. I deliberately have not done anyread-write 
> tests because I do not want to aggravate the failing disk.

I think the errors in your disk only appear in cluster reads; when 
reading several sectors at once. Then, when reading sectors one by one, 
all of them read good.


Best regards,
Antonio.