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

On 2020-08-14 02:56, Paul wrote:
> 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


Mostly over my head but thank you very much all the same!