Re: disk bad block checking post-install / ext2

From: prg (
Date: 01/12/05

Date: 11 Jan 2005 15:50:23 -0800

Jules wrote:
> On Tue, 11 Jan 2005 08:06:13 -0800, prg wrote:
> > Jules wrote:
> >> Hmm,
> >> a) does anything exist to run a disk check whilst maintaining
> > filesystem
> >> integrity,
> >
> > 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
> 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
> same model as the failing one, so in theory that makes life very
> a simple dd from the failing drive to the new one should be all I
> rather than messing around with doing an OS install and copying data
> across...
> > Check if you can get a disk diagnostic/repair utility from the
> >
> Is it worth it though? Presumably if a drive's developing bad blocks
> due to wear / contamination and will only get worse? In other words,
> just better to throw the drive out and replace it...

It runs the _maker's_ diagnostics -- they are largely used for maker's
QA but you can get some indication of "shelf life" running the full
test. And they can _forcibly_ re-map some bad sectors that others will

If you backup your data and _zero_ the disk, I think most of the
utilities will rebuild their own bad blocks _table_ and reserve
_new_space_ for the transparent re-mappings. The test results should
give some indication of the viability of continued use

> > As noted, you only have so much spare disk space for remapping.
> > 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
> remap on reads or writes (In my experience with IDE disks - which
> seen cause a few problems - they silently corrupt on reads a long
> before they start giving write errors)

Even with the hd's re-mapping space filled, a good/timely use of
badblocks could mark sectors bad, thus informing the fs to avoid those
bad sector writes. Depends on running badblocks at the right time ;-)

> > Badblocks is best run at fs creation time, but is handy afterwards
> > But to use it you must _know_ what you're doing _and_ generate a
> > 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

email above disabled