bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Another bug on -J drives: trim mode is actually scrap


From: Self
Subject: Re: [Bug-ddrescue] Another bug on -J drives: trim mode is actually scrape mode
Date: Sat, 19 Dec 2015 17:20:28 -0700

Thanks!

A workaround: if I set read size to 1 sector (-c 1), then I can read forward or 
backward 
correctly.

Some further hints...

- At least for -J drives and maybe others, there's a significant difference 
after phase 1 
between skips due to slow areas, and skips due to read failures. The former can 
likely be 
fully read later with no user interaction... it will just read slowly. The 
latter will most likely 
take a lot of time.

For this reason alone (and others), I would suggest distinguishing slow-skip 
from 
error-skip in the log.

- In my experience, there's a significant difference in speed and likelihood of 
data 
retrieval, between two types of regions:

Low Probability: Errors already seen (*,-) and/or skips and read data are about 
the same 
size (e.g. read 128k, skip 64k, read 256k, skip 64k)

High Probability of success: skips are small relative to good areas... and 
reading (? or *) 
from the side with good data (e.g. if - ? +, better chance of getting data 
while reading it 
backwards)



On 17 Dec 2015 Antonio Diaz Diaz said...

>address@hidden wrote:
>> - The front is read until a bad sector, which locks the drive
>> - This first run expands the previous '+' block
>> - Next run (after drive restart and ddrescue restart) gets no
>data
>> and the bad sector is marked (Now we have: + - * +)
>> - Next run **continues from the front** and either finds new good
>> data or adds another
>> bad sector to the '-' block - And so forth. *** end of block is
>never
>> trimmed; this is effectively scrape mode ***
>
>True. Maybe ddrescue should trim from the end of the block when it
>finds 
>(- * +), and perhaps mark the block as non-scraped (without trying to
>read it) if it finds (- * -).
>
>I'll do some tests and see what happens.
>
>
>> If we try using -R reverse, it **still** trims from the front of
>each
>> block. Reverse apparently only affects block sequences, not what
>> happens within a block, at least in trim mode.
>
>This is also true for scrape mode because reading forwards is usually
>faster than reading backwards inside a block.
>
>
>Best regards,
>Antonio.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]