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
_______________________________________________
Bug-ddrescue mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-ddrescue
