Re: "Repair" hard disk with bad sectors by reading and rewriting same data?

Percival P. Cassidy wrote:
> I have a 6TB drive that shows 8 bad sectors. Would it be possible to 
> repair it without harm to the data using
> 
> dd if=/dev/daX of=/dev/daX (and perhaps with bs settinng as well) ??
> 
> Perce

This depends a lot on how you've concluded you have 8 bad sectors.

ATA (either IDE or SATA drives) have automatic sparing.

There are a certain number of spare blocks "within reach" of a
given block. Say for example, there were 32 spare sectors per track,
then if one sector was unrecoverable, the sector could be replaced
by a good sector. The replacement might happen during a write, so
fresh data goes into the sector. If any reads were attempted, the
read-tries occur for 15 seconds, so 1800 tries happen in the hope
the data can be read. Sectors which took a lot of tries to read,
are put in a queue for processing on the next write to the
area. The blocks that are remapped, pointers are kept in a table
in the cache RAM, for quick access during normal operation.

The SMART has

    Reallocated       Raw Data = 0

    Current Pending   Raw Data = 0

There was a theory, that the sectors of poor quality (needed the 1800
read-tries), those show up as logged in Current Pending. And as the
drive whittles them down and resolves them, they cause the Reallocated
to be incremented. However, my experience with Seagate at least,
is the Current Pending indicator only starts to increment, when the
drive is in serious trouble and is throwing CRC errors. Whether each
Current Pending block is a CRC error block, who knows. I don't have
enough sick drives, to be making finer interpretations than that.
All I can tell you is, Seagate behavior, does not match the Internet
description of how it works.

It's because there is Automatic Sparing, that the drives can be "repaired"
in a sense, by applying an external stimulus. Writing the drive
from end to end, allows an opportunity for evaluation of the various
tables of badness. The operation "harvests" blocks that needed
attention, and the result is, the SMART table then is a better
reflection of current conditions.

In the old days, with SCSI drives, sparing was also reset-able by the
operator. There were "factory defects" and "grown defects". A person
could manage the defect lists if they wanted. I tried doing that
once, by removing the grown defects, and scanning the drive, and
the grown defects, to a man, all came back. Which proved they
really were defects. Even if your current 6TB drive were a SCSI
drive (SAS maybe), and you messed around like that, the status
of the media is unlikely to change.

The Reallocated also have weird growth characteristics. I
correlate growth there with room humidity. The drive
has a breather hole, and while there is a labyrinth to
prevent moisture entry, if the AC is off in the facility
for a month or so, whatever moisture problem is evident
there, it could get into the drive. The Reallocated would
be seen to increase, when you rewrite the drive from
end-to-end, and new suspect sectors are processed and
replaced with spares. I have drives here, where the
Reallocated have (more-or-less) stopped growing, so
if you see a "growth rate", if you remove the
stimulus (get the AC working again), the humidity
drops and the drive might not get any worse.

A Helium-filled drive, doesn't have that exposure.
The Helium could (and will) leak out. The drive is
guaranteed to have Helium for five years, before the
adhesive in the cover lets it all escape. The adhesive
eeam is "wide", in an attempt to provide as much of
a barrier as possible. And it was considered that
the adhesive method would be better than a weld. The Helium
drive may have two covers, a Helium seal on an inside cover,
and a cover plate for mechanical protection (so if
Willy squeezes the drive in his fat fingers, it
doesn't immediately destroy the seal). But at
least with a Helium drive, there's no way for
water infiltration to be an issue with the media.

Summary: Go ahead and write it, expecting Reallocated to grow
          according to the number of suspect sectors already present.
          The write operation is like a "harvest". If a sector has
          thrown a CRC error in the past, it's still going to do that,
          as it got that way because the disk area has run out of
          spares to fix it.

          Verify the semantics of "dd", by using a VM, writing
          a random pattern on a small data drive in the VM first
          with dd. Then, do a "copy" pass as proposed. Then
          read out the drive and compute a checksum and see if
          the "before" and "after" checksum on the "copy" operation
          are the same.

          As far as I know, "dd" does read before write, but I don't
          know if there are any corner conditions to be concerned
          about or not. If the drive will not sustain an unadorned
          dd operation attempting to read it from end to end,
          then you don't want to try your copy pass. The copy pass
          would be reserved for "good times", where to the best
          of your knowledge, every write attempted by dd, would succeed.

          The gddrescue has more recovery options, such that its
          copy semantics are less likely to cause grief. It maintains
          a logfile with data on what sectors kicked up a fuss.
          Repeated runs can be used to "resolve problems" and
          reduce the outstanding work shown in the logfile. The
          package name in Linux is "gddrescue", but the executable
          at runtime is "ddrescue". Block size on transfers, is variable,
          and the program can gear down to "doing single sectors" if it wants.
          Regular dd is more likely to do fixed values of "bs=" size.

          Practice on a VM drive *first*, before unleashing these
          lengthy lengthy operations on a 6TB drive. All that a VM
          drive can test, is that the basic operation works OK, not
          that all the corner cases are handled. A gddrescue operation
          on a virtual drive, will have an empty logfile. Or at least
          the symbols indicating no work remains to be done. It won't
          be a particularly human-readable format, because the notation
          also seeks to compress the size of the logfile and not make
          it huge-beyond-words.

    Paul