Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |