|Subject:||Re: [Bug-ddrescue] user-interface suggestions|
|Date:||Wed, 20 May 2009 18:24:40 -0400|
|User-agent:||Thunderbird 184.108.40.206 (Windows/20090302)|
Antonio Diaz Diaz wrote:
* Is it appropriate to use -d at all? Are the block sizes correct? Does my system support this? That's what I suggest should be automated.Here is where the art resides. -d may be faster or slower than cached reads. There may be several valid combinations of block size / read size. All of it depending on the type of medium and OS.
From my experience, the -d option has only been faster (Using various Linux distributions, like Mandriva, CentOS, Trinity and RIP)
Without it I have had drive rescue operations take 4-5 days, but when using the -d switch, the same operation would take about 8 hours.
As I understand it, the -d option affects whether ddrescue get affected by any OS read ahead options.
So if you have OS read-ahead default set to 16384 bytes, and ddrescue reaches an area with lots of bad sectors then ddrescue has to wait for the drive to stutter, timeout and retry it's way through the to 32 (16384/512) bad sectors.
Whereas if you use the -d option, ddrescue won't be as fast on good areas (Sequential throughput suffers without readhead), but when it hits a bad sector it will quickly skip and move on to other good parts on the drive, rather than get caught up because the OS tries to readahead a whole cluster of bad blocks.
Anyways, it's been a few months since I last looked at all of this, maybe what I am saying is hogwash, but after seeing a 4 day recovery being done in about 8 hours, I now always use the -d option.
-- Regards, Kim Pedersen
|[Prev in Thread]||Current Thread||[Next in Thread]|