[RndTbl] Open Source Backup/cloning to USB HDD

[Adam Thompson]

Unfortunately, based on how the drives are *designed* to operate, seeing any
bad sectors at all is NOT NORMAL and probably indicates upcoming failure of
the drive.

All modern drives (IDE, SATA, SCSI & SAS, anyway) reserve an entire track
(or more) for bad-sector remapping.  The firmware automatically remaps any
sector that requires more than X number of retries to read or write
successfully.  This is done transparently to the user, operating system,
ATAPI controller, etc. - it's handled 100% internally.

IF the remapping operation fails, then - and only then - will the read or
write command fail and the bad sector will be reported.  The main reason for
sector remapping operations to fail is that all of the reserved area is used
up.  Sometimes there are many bad sectors in the vendor-reserved area, which
dramatically decreases the number of successful remapping operations that
can take place; sometimes it's simply not possible to read the contents of
the old, failed, sector no matter how many retries; there are a few other
reasons that vary from one manufacturer to the next.

But, basically, if the OS is reporting bad sectors, it's time to replace the
drive because the drive can no longer perform its own defect management.  If
you use a tool to examine the drive's SMART response, you'll often see a
fairly low number of allowable "bad sectors" - this, too, varies from one
manufacturer to the next - because each manufacturer does allow (for
warranty purposes) a larger number of sectors to fail than are guaranteed to
be remapped successfully. Use a SMART-aware tool to invoke the drive's
"Long" self-test, and if necessary, return the drive for repair or replace
it.

Some spurious read errors may be considered normal; sometimes a drive will
attempt to remap a bad block, fail to do so and report the error, then try
again and succeed the next time that sector is accessed.

It may be considered "normal" that if your drive comes with a one-year
warranty, then after that one year, you will gradually develop more and more
bad sectors.  So any system that isn't brand-new is likely to have some bad
sectors.  Outside the warranty period, there's no "rule of thumb" for how
fast those sectors crop up - so even if you have a two-year-old system, you
might already be seeing bad sectors beyond the drive's capability to remap.
 Note that many modern file systems do not provide any reasonable way to
dynamically grow the bad sectors list any more.  I would nominate ext2 and
ext3 in that list as well as HFS+ and NTFS... not that it's impossible, it's
just not reasonably easy for a user to do so.  For that matter, I can't
think of a single modern FS other than FAT32 where it *is* reasonably easy!


Bottom line: bad sectors are bad.  You shouldn't see them on modern hard
disks.  But you probably will.  And yes, they really do mean your drive is
going bad - but it might still have many usable years left.


On Tue, Oct 27, 2009 at 18:37, Dan Martin <ummar143 at gmail.com> wrote:

> One problem I have encountered is IO errors, especially when copying large
> volumes.  The 'noerr' option allows the copy to complete, but of course does
> not correct the problem.  I have had one or two errors on every second
> drive.
> [...]

I can't find any material that explains how this works -- what I surmise is
> that the drive firmware hides defective blocks.  Obviously it does not hide
> them all, or at least not instantly - so the file system tracks bad blocks
> that the firmware has missed in order to avoid using them in files.  Using
> dd circumvents the file system, so there is a risk of a corrupt file on the
> target drive/partition.
> [...]
> The drives seem OK in every other respect, and software that monitors the
> status of the drives does not indicate any impending failure.  I am
> guessing, based on a small sample, that this is a 'normal' condition.



--
-Adam Thompson
<athompso at athompso.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.muug.mb.ca/pipermail/roundtable/attachments/20091027/54e8086b/attachment.html