Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] unreadable sector

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>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /