[Discuss] unreadable sector

[Jerry Feldman]

On 10/12/2013 02:42 PM, Tom Metro wrote:
> 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
>
Thanks guys. My plan is to remove the drive, and run the destructive bad
blocks, then reset the partition table, reformat the file systems and
resync into the RAID. If I get a chance I'll stop at MicroCenter and
pick up another drive. I'm not too concerned about running with a
degraded array for a short time because of my backups.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90