[Discuss] unreadable sector

[tmetro+blu at gmail.com (Tom Metro)]

Jerry Feldman wrote:
> ..would I be better served by removing this from the RAID pair,
> and run a full destructive bad block scan 'badblocks -wsv /dev/sda ...

Yes. Even a non-destructive read-write scan (-n), followed by a RAID
resync would do the trick (it'll make logwatch stop reporting problems),
but if you're not in a rush, doing a destructive scan with multiple
patterns and a few passes, followed by a RAID resync would be safer and
more thorough.


> The bad blocks scan should (1) reallocate the bad blocks and also give
> me more detailed information on whether to replace the drive or not.

It will provoke the drive's firmware to reallocate, but I don't think it
is going to tell you anything you couldn't have gotten from SMART,
unless the write testing turns up additional bad blocks.

I recommend that you capture to a file the SMART attributes before and
after your bad block scan and diff them so you can see whether failure
predicting counters have increased.


> I'm not worried about this as this otherwise seems to
> be a serviceable drive and I take frequent backups.

If it is a non-critical drive, and the defect area doesn't start
spreading when you run the above tests, I'd be perfectly comfortable
continuing to use the disk.


Edward Ned Harvey wrote:
> ...bad blocks on disk are like rust. It's a chemical defect, 
> and it spreads.

Sure, that's a common failure mode for disks, but by no means the only
way defects behave over time. I've had drives develop a small number of
bad blocks early on in their life and then remain perfectly stable for
years.


> badblocks, by itself, only makes an attempt to identify bad blocks,
> and store them in a list usable by something else such as mkfs.

badblocks has several operational modes. The one you describe is the one
used when it is invoked by "the -c option of the e2fsck and mke2fs
programs."

badblocks can also be used stand-alone to do read-only tests,
non-destructive read-write tests, and destructive write tests. The
latter two repair problems by provoking the drive's firmware to
reallocate defective blocks, and thus no coordination is required with
the file system. (If there was a file system, the latter option will
obviously necessitate reformatting, and the former will likely require
some fsck repairing.)

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/