Re: [Bug-ddrescue] Quick question about -c parameter

[Antonio Diaz Diaz]

Hello David. Glad to read you again!

David Burton wrote:
> I have a quick question about the -c parameter
> <http://archive.is/TDPbg#selection-1046.3-1073.179> to ddrescue. When
> recovering data from a drive with 512-byte logical sectors but 4096-byte
> physical sectors, which of those does the -c parameter specify?  If I want
> it to read 4K at a time should I specify -c1 or -c8 ?

I guess you mean the '-b, --sector-size' parameter. It is important to 
tell ddrescue the physical sector size of the input device through the 
-b option to prevent discarding good data, as shown in the Stack 
Exchange link below.

The -c parameter is not so important. It mostly affects speed; the 
larger, the faster, until it is too large.

The right parameters for your case are then '-b4096 -c1'.


> I see that I'm not the only one wondering about this:
> https://unix.stackexchange.com/questions/245471/which-sector-size-shall-i-choose-to-run-ddrescue-with-direct-access-on-an-advanc

From the link above:
"What doesn't seem normal is having a 512 b bad sector like in this 
screenshot:"

It is normal if, as in the case related in the link above, one switches 
from -b512 to -b4096 in the middle of the rescue. A sector that fails to 
read may be read successfully in a second attempt, but ddrescue will 
write to the output file only the tried part of the sector.

Currently, if a 512-byte sector is marked as bad-sector during the 
trimming phase, it will not be tried again during the scraping phase. To 
prevent this from discarding good data because of a changing -b, I can 
improve ddrescue so that during the read of the mapfile it incorporates 
non-finished blocks smaller than the sector size into its corresponding 
sector (if it is also not finished), marking all the sector with the 
less processed state, so as to make sure that sub-sector data is not 
discarded from a successful sector read.


> Are you active on StackExchange? You could post an answer, if you are.
>
> Or I could do it, if you'd like.

Thanks. I'm not active on Stack Exchange or anywhere else. I'm too busy 
writing and testing software. If you post an answer on Stack Exchange, 
please, add that this list is the right place to report unexpected 
results so that they can be fixed or documented.


Best regards,
Antonio.