Re: disk bad block checking post-install / ext2
From: Jules (julesrichardsonuk_at_remove.this.yahoo.co.uk)
Date: Tue, 11 Jan 2005 21:36:47 +0000
On Tue, 11 Jan 2005 08:06:13 -0800, prg wrote:
> Jules wrote:
>> does a utility exist to check a (SCSI) disk for bad blocks after
>> It seems that badblocks is designed to run at filesystem creation
>> only (and really designed to be called by the relevant mkfs utility).
>> One of the 18GB SCSI drives in my home fileserver (ext2 filesystem)
>> starting to throw up the occasional disk error on the OS drive, and
>> although I have a spare I can use I'd rather check other options
>> a) does anything exist to run a disk check whilst maintaining
> As others noted, $ man badblocks -- _very_ carefully.
> Also, check if you have smartmontools on your distro. $ man smartd
Ahh, yes I do! Hmm, that looks particularly useful, I'll definitely give
that a go (hopefully the SCSI drives I'm using support it!).
I've found that my spare 18GB drive that I have on the shelf is the exact
same model as the failing one, so in theory that makes life very easy;
a simple dd from the failing drive to the new one should be all I need
rather than messing around with doing an OS install and copying data
> Check if you can get a disk diagnostic/repair utility from the maker:
Is it worth it though? Presumably if a drive's developing bad blocks it's
due to wear / contamination and will only get worse? In other words, it's
just better to throw the drive out and replace it...
> As noted, you only have so much spare disk space for remapping. And
> the re-mapping is only available on first write -- it the hd can't
> _read_ the block with data it will _not_ re-map.
Wow - that's a useful bit of info; I didn't know that. I'd assumed it'd
remap on reads or writes (In my experience with IDE disks - which I've
seen cause a few problems - they silently corrupt on reads a long time
before they start giving write errors)
> Badblocks is best run at fs creation time, but is handy afterwards also.
> But to use it you must _know_ what you're doing _and_ generate a table
> that the fs can read/use to avoid badblock marked blocks.
As said in another response, I did do that 6 months ago and it threw up no
errors then. I'll have to check airflow in the server case too; maybe
I've got a heat-related problem that's killed this particular drive...