Thread (21 messages) 21 messages, 9 authors, 2016-10-11

Re: Why not just return an error?

From: Anthony Youngman <hidden>
Date: 2016-10-10 20:47:04


On 07/10/16 18:44, Dark Penguin wrote:
I actually wanted to ask about that. Can you really ddrescue a drive
with a "hole" in it, re-add it and expect it to work?.. What happens if
you try to read from that "hole" again? And while I'm talking about
re-adding, when does it become impossible to "re-add" a drive?..
If you want to do some kernel development work, this is something you 
can do something about :-)

ddrescue creates a log of sectors that failed to copy. I've been 
thinking a bit about this, not least because other people have mentioned it.

Modern disk partitioning tools usually leave a chunk of space. What we 
want is some way of making ddrescue dump a signature on the disk, along 
with a list of all blocks that failed to copy. Then we need to patch the 
low-level disk access code so that it reads this list of "bad blocks" 
and returns a read error if any attempt is made to read one. If a block 
is written, it's removed from the list. In effect, this is a "bad block" 
list, only instead of being at the disk firmware level, it's at the OS's 
disk driver level.

That way, at least you know, if you copy a damaged disk with errors, 
then the filesystem layer will be told that the file is damaged, rather 
than returning duff data with no indication that it is duff.

THIS IS NOT THERE TODAY, but if you want a kernel project, this isn't a 
bad one. This will mean that you can recover a broken raid with no data 
loss, provided you have enough drives to be able to assemble a redundant 
array, and you aren't unlucky enough to have two drives have an error in 
the same place.

Cheers,
Wol
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help