[Tfug] Drive recovery

[Bexley Hall]

--- On Wed, 6/3/09, Bowie J. Poag <bpoag at comcast.net> wrote:

> dd is completely unaware of what a sector is -- It's completely 

My bad, I didn't expect to be taken literally.  :-(
s/when the sector(s) in question return read errors/when a read(2)
encounters the defective sectors and returns an error/

> agnostic when it comes to input. The idea is, recover what can be 
> recovered--there's no point in obsessing over  the
> unreadable. Since 
> we're telling it to read off a block device, it becomes the
> responsibility of whatever storage driver is handling the
> requests to satisfy dd. All dd wants is "next, until there 
> is no more "next" to read.

dd(1) doesn't have any special magic to talk directly to
a device.  It relies on read(2) -- or related -- to do the
dirty work.  The OP commented that "read's" were returning 
errors.

My comment was that dd(1), relying on read(2), will see the
same errors returned.  How dd(1) handles these errors is
something I can't attest to without looking at the sources
(hence my comment).

The read(2)-write(2) loop that lies at the heart of dd(1)
has to decide what to do when read(2) returns an error.
This can be either a short read (nread < nsought) or a
"real" error (e.g., EINTR).

If the loop is fabricated as:

while (FOREVER) {
   nread = read( IN_FD, buffer, sizeof(buffer)/sizeof(buffer[0]) );
   if (nread == 0)
      break;
   (void) write( OUT_FD, buffer, nread );  /* XXX FIXME XXX */
}

then a short read won't terminate the operation -- it will wait for EOF.

But, if the terminal condition is (nread <= 0) then you are at
the mercy of the underlying device read as to when it signals a
genuine error.

> The resulting iso image might be sane enough to repair and then 
> have its contents dumped into a new filesystem.

You'd have to either KNOW where the "bad block" was in the filesystem
image or, have a tool that can check the integrity of the image
while offline.  It would help if you could just look at an arbitrary
FSBN via od(1) et al.