Richard Neill wrote:
May I suggest a few more sentences of documentation would help? In the common case (a modern Linux or BSD system), is it fair to say that -d will work? If ddrescue is invoked with -d, but direct access isn't possible, will it fail gracefully, or will bad things happen? How can I find out whether the hardware block size is correctly set?
Yes. I'll try to answer these questions in the manual.
* 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.
* 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.
That's probably unnecessary here, but I think that USR1 should be trapped and *ignored* rather than treated the same as SIGINT.
OK. Ignoring it is as easy as handling it. Regards, Antonio. _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
