How to read bad blocks error message & marking of same

[Bill Vermillion]

> Send freebsd-hackers mailing list submissions to
> 	freebsd-hackers at freebsd.org

> ------------------------------

> Message: 2
> Date: Fri, 6 Aug 2004 18:13:51 -0700 (PDT)
> From: stheg olloydson <stheg_olloydson at yahoo.com>
> Subject: Re: Fwd: How to read bad blocks error message & marking of
> 	same
> To: questions at FreeBSD.ORG
> Cc: hackers at FreeBSD.ORG
> Message-ID: <20040807011351.51693.qmail at web61309.mail.yahoo.com>
> Content-Type: text/plain; charset=us-ascii

** [the posted message had the original writers attributions removed
** - I've reformated to take out excessive >'s inserted by one of
** the posters mail reader/reply system and to bring back standard
** paragraph formatting and line lengths. I used 'par' from the
** /usr/ports/textproc in FreeBSD - wjv]

> it was said:

> > > >>>Modern drives deal with bad block substitution all by
> > > >>>themselves.

> > > >>Umm - not quite, right? That is, if a block "goes bad"
> > > >>and you get a read error, the drive isn't going to do any
> > > >>"substituting" at that point. You'll just continue to get
> > > >>the read error if you try to access (read) that block.
> > > >>It's only when you allow another *write* to that block
> > > >>(e.g. by deleting the original file and writing new files)
> > > >>that the drive will automatically substitute a spare block
> > > >>for the one that went bad.

> > > >SCSI drives, at least, may do automatic reallocation on
> > > >both reads and writes ( camcontrol mode da0 -m 1, the ARRE
> > > >and AWRE flags ). If the drive had to reread the block or
> > > >had to use ECC to recover data, AND the entire block was
> > > >recovered, it will relocate the data if ARRE is set.

> > > Good to know, although I stopped buying SCSI disks (for home
> > > use) years ago. I presumed the more common case these days,
> > > that we were talking about IDE disks. In fact doesn't this
> > > (from the original question):

> > > ad0s1a: hard error

> > > necessarily refer to an ATA (IDE) disk? I don't believe
> > > any (current) ATA disks will do automatic reallocation on
> > > reads, will they? Though of course serial ATA drives seem to
> > > be "the future" and are taking on more and more SCSI-like
> > > features as time goes by.

> > Both ATA and SCSI drives may relocate blocks that were difficult
> > to read (e.g. correctable errors, took multiple attempts, etc).
> > But if the block can't be recovered at all, the drive will still
> > report an error to the OS (in addition to relocation).

> Hello,

> A tool that all may find useful is SpinRite 6.0 available from
> Gibson Research at http://www.grc.com/sr/spinrite.htm. It's not
> open source or freeware but anybody with an Intel, AMD, or TiVO
> system that uses a harddrive ought to have it. Note: I am in
> no way affiliated with Gibson Research, other than having used
> SpinRite since the days of manually interleaving MFM drives.

Having watched Gibson Reasearch from it's earliest days I've formed
the personal opinion that Steve spreads a lot of FUD that may have
a grain of truth but takes that grain and sows and entire field
with it.

I've also been using Unix systems since 1983 and Gibson's products
are targetted more toward the MS world.  He originally promoted his
products with the idea that you had to reformat the hard drive
every few months as the domains start losing their magnetiziation.
That's pretty much hogwash.   

However what he said may have been true but not for the reasons he
stated.  HDs all used stepper motors in that era.  His program
could overcome the problem that a worn stepper could cause - not
positioning properly over the tracks as they were originally
formatted with new steppers.

Then we went to dedicated servo platters - which elminated the
stepper but that >could< have problems if the heads on the stalks
changed for some reason.  Embedded servo writing took care of all
that as the servo was in the same track as the data and was
self-aligning.

Spinrite or others are a very good tool in the MS oriented world,
but I find them [my own observation and that of people I know and
trust] un-needed in Unix systems if you use decent hardware.

The Spinrite article says a drive may last a decade if you turn it
and the computer off every night.  Other shcools of thought say
that can cause more problems than it cures as you have daily
current inrush and thermal changes.

I've never had a drive last a decade as I've always needed
something larger.  My two longest lasting HDs were both running
24x7 - one on a news machine and one on a mail server.  The first
was an ESDI with additional sectors on each track so that any
failed read would turn on ECC and the track would be re-written
with the bad sector numbered as zero and hence invisiible. If you
used up the spare sector then the ECC would write that track
to a new track and make the old track invisible.  This was in the
HD and totally transparent to the OS.

That drive ran for 7 years 2 months and 2 weeks.  I would see
the notifications in a message to the console any time a track was
reformatted and/or moved to another place.  I decided to see how
long the drive would go - and in the end I was unable to determine
if the drive failed or the controller failed.  And by that time
15Mhz ESDI controllers were impossible to find.  The drive was a
Maxtor.

The other drive that ran almost 7 years migrated from one ISP to
another.  I replaced it after I made one of my rare trips to the
colo and noticed there was noise from the HD that was heard above
the noise of the 4 Liebert air-handlers in the colo.  That was
a SCSI 'cudda.   The bearings were getting really bad.

As one of the other posters notice SCSI and drives designed for
server work - not made to be the cheapest desk-top just run and
run.

I bought a half-dozen 'as-is' HDs that had been pulled.  A couple
were totally shot.  These were IDE in the 10MB range.  I dl'ed the
manufacturers utitlities for the drives that had them, ran them,
and things came to life.  I found Spanish versions of Windows.

The MS format and 'recovery' utilities had failed on these, just as
Spinrite indicates.  

I've found no need for things such as SpinRite in the Unix world.
I'd like to hear from others who have found the opposite.

Bill

-- 
Bill Vermillion - bv @ wjv . com