Date: 27 Oct 2003 20:37:52 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: freebsd-questions@freebsd.org Subject: Re: hard disk problem Message-ID: <4465iauopb.fsf@be-well.ilk.org> In-Reply-To: <3F9DA59C.1020109@whatistruth.net> References: <020701c39c50$00f4b620$8201100a@yugovostok.transtk.ru> <44fzhewz65.fsf@be-well.ilk.org> <3F9D6614.6040009@whatistruth.net> <448yn69z2s.fsf@be-well.ilk.org> <3F9DA59C.1020109@whatistruth.net>
next in thread | previous in thread | raw e-mail | index | archive | help
DavidB <odyseus00@whatistruth.net> writes: > Hey, Lowell could you please read the thread I reference and give your > opinion of the issue about the WD diagnostic tool. Most manufacturers have their own versions of such tools. If you can use them, they are indeed quite likely to give you more information than you can get any other way. > So I was studying what you were talking about bad block remapping, > dynamic bad block remapping, or western digital's term "Auto Defect > Retirement" > > I had expected that I disk would when failing to write to a bad area > on disk and fails to mark it bad and redirect it to somewhere else on > the disk. But reads I would not have expected the hardware to do > anything other than give a failure. It seems there is some mechanism > to do this automatically within the hardware with reads also. But it > seems very vague on how and when this is tripped. Most of my reading > including one thing from someone who works for Maxtor is that the bad > block is marked bad at the failed read (or succesive failed reads, > says the Maxtor guy) however doesn't get remapped until the next > write, and from my reading, seems to be, not until the next write to > that particular sector. So the bad block being read would be there > until you did something to cause the hardware to remap it. It doesn't > seem it is done so it is totally hidden from view or seeing issues > with bad blocks. This seems to differ a little between manufacturers, but I think most of them have a few more complexities than that description. One of the more impressive tricks is to re-try failed reads, starting from a different sector on the cylinder (and thus, a different timing, which improves your odds of a good read if you're having problems with the platter-to-head separation). More expensive drive firmware will certainly recover the problem sectors automatically -- I suspect, but do not know for certain, that some drives will first try re-writing the data back to the same sector, in case field strength just needs reinforcing. > The system seems to be setup in order to catch problems and remap them > at the earliest time so that the data is not totally unreachable[lost] > the hardware will try using multiple reads with ECC to read out the > effected data [from what I have read] and writes it somewhere else. Of course, you won't hear about it at that time. > So again I say that the disk PROBABLY is NOT in for a soon demise. > Running the disk diagnostic tools from the disk manufacturer will > remap the bad block immeadiately as well as other things, rather than > waiting until you happen to write to that sector again. Yes, I did "pull the trigger" a bit fast on this; it's possible that the two errors reported by the original poster were the only ones observed. In that case, they could be a fluke for any number of reasons, right down to sunspots. I probably should have recommended being *prepared* to replace the drive.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4465iauopb.fsf>