> Send freebsd-hackers mailing list submissions to > [EMAIL PROTECTED]
> ------------------------------ > Message: 2 > Date: Fri, 6 Aug 2004 18:13:51 -0700 (PDT) > From: stheg olloydson <[EMAIL PROTECTED]> > Subject: Re: Fwd: How to read bad blocks error message & marking of > same > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
