Re: disk bad block checking post-install / ext2

From: prg (rdgentry1_at_cablelynx.com)
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,
[snip]
> >> 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
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
> across...
>
> > Check if you can get a disk diagnostic/repair utility from the
maker:
> > http://www.duxcw.com/faq/hd/diag.htm
>
> 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...

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
miss.

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.
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)

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
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...

hth,
prg
email above disabled