Vulcan wrote:
XXL wrote:
I woud like to ask why is gddrescue perceived to be a better tool than dd - they seem to recover the same amount of data?
In
theory it would be possible to duplicate the behaviour of GNU
ddrescue (package
gddrescue) by using
dd, if the technician involved was very skilled and if they made no mistakes during the process. However in
practice, using
ddrescue requires less skill (though it still needs some skill for
best results) due to its built-in algorithms & logging, and typically has better & less-risky results, partly due to preventing the human errors which could otherwise easily occur if trying to use
dd manually with many different parameters, and making it easy to control the relevant tuning of those parameters. The specific benefits of using
ddrescue also depend on the problems with a given disk (e.g. just one unreadable block on the disk, or 1000 marginal blocks in different places on the disk which might be readable with extra retries, or ... etc. etc.)
In short, the advantages of using
ddrescue make it a "no-brainer" choice over
dd, for reading from imperfect disks (and in some other situations), in my experience.
(Note: This is just comparing
ddrescue &
dd - it does not address the risks / problems which are common to using either program.)
I see. Could you elaborate a bit further on
gddrescue, namely are there any other useful built-in algorithms apart from a block-size-changing one? I found the benefits of this feature to be somewhat of little help when dealing with a disk with large amount of bad sectors due to extremely long execution time -
gddrescue will only decrease the block size on the second run, which will trigger the same delay when encountering a bad sector. So, the execution time is already at least doubled. Won't the best practice in this case involve a simple run of
dd with the lowest block size (512B), instead? This is, of course, in regards to a drive with many bad sectors - AFAIU, running
gddrescue with a large block size on a drive with only a few bad sectors will be more desirable speed wise, as thanks to logging
gddrescue can start an automated N number of passes, while adjusting the block size, for attempted post-recovery.
I've mostly ran
dd with only 3 flags:
direct,
sync (for padding with
NUL) and
noerror, all of this with a block size equal to a sector - this has given me the best results (although noticeably slow due to direct I/O). Is there any other flag that would influence recovery for
dd? Or, perhaps, some feature of
gddrescue that is able to do even more?
I have to ask again - how can I put the drive into
PIO mode (from what I read this should aid recovery)? Presumably this is done through
hdparm -X? This command never worked for me, for some reason. The error I'm getting is something like this:
SG_IO: bad/missing sense data. What other known working method is there for
PIO mode switching?
At the very end of your post you mention the risks associated with running these apps - may I ask what are they and what is perceived a better alternative (somewhere I read about
Data Extractor feature of
PC3K)?
Finally, when making a raw binary image with
dd or
gddrescue, is there a way to somehow evade the massive delay (I/O err of about 10-15 seconds) when encountering a bad sector? Perhaps, some kernel setting? A surface scan with
mhdd goes significantly faster than the time spent upon detection by the Linux kernel - I guess, this is influenced by the error reporting mechanisms or large predefined timeout values in it for such encounters?
As of again, any input on this is greatly appreciated!