[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Bug-ddrescue] Another bug on -J drives: trim mode is actually scrape mode,
Self <=