Re: [Bug-ddrescue] user-interface suggestions

[Richard Neill]

Antonio Diaz Diaz wrote:
> > May I suggest a few more sentences of documentation would help? 
>
> Yes. I'll try to answer these questions in the manual.

Thanks.

> > * When should -d as opposed to -n be used?
> >   I think this is what you refer to as an art.
>
> This is not an art at all. -d and -n are totally unrelated options. You 
> can combine them as you like. -d determines how to access the data, 
> while -n makes ddrescue stop after the trimming pass.

Sorry - my brain was quite clearly failing when I wrote that. What I 
meant was whether to use -d or not to use it.
> > * 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.


Here lies the problem. It's going to be hard (I think) to write a 
suitable heuristic for ddrescue.
But the user certainly doesn't know. And trying to acquire the "art" at 
the moment of panic when rescuing a damaged disc is not going to work.

There's no easy way out of this. I assert that the art ought to be
in the program, rather than the user (because that way, the author has 
to do the work once, as opposed to each and every user learning for 
himself) - but of course that represents a lot of work for you.

Is there any way to simplify the heuristic such that ddrescue can make 
its own decisions about what is "nearly" the best outcome? It doesn't 
have to be spot on. But at the least, ddrescue should protect the user 
from any bad consequences of the misuse of -d.

Regards,

Richard