My original query had to do with
>> I've now taken the drive off-line and am trying to reformat it;
>> unfortunately, I'm getting lots of messages about
>>
>> Warning: unable to pinpoint defective block.
>>
>> when doing surface analysis.
Per Westerlund provided a concise explanation of the message:
> My guess is bad cabling or a bad terminator somewhere; the message
> "unable to pinpoint defective block" really says that a perceived
> defect is not permanent, it looks like lots of random errors, and that
> is usually bad cabling. Of course, if there is some pattern to the
> errors, always on a specific head or something like it, the it might be
> the drive itself.
This was seconded by David Robinson:
> My past experience has found that those warnings are more typical
> of a controller or cabling problem. What often happens is that a
> bit gets dropped so format attempts to reread and find the block but
> the error does not reoccur so it warns you.
With this in mind, we're going to bring the machine down shortly
to re-seat the controller and check all cabling. Hopefully this
be all that's needed.
A few other people were of the opinion the disk should be replaced.
Unfortunately, budgetary constraints and the like make this the last
recourse right now.
Fabrice Le Metayer suggested "your defect list may have
become corrupted (or wiped out) for some reason. Try entering the defect
list by hand (yes, all 200 of them!...) before reformatting".
We had the forethought to dump defect lists to files when we received
new disks so this isn't all that painful but it isn't our problem
in this case either.
Curt Freeland mentioned I should "use a smaller transfer size when
doing the data analyze on the drive" in the hope that "if it finds an error,
it has less work to do to pinpoint it". Trying this led to no fewer
error messages and took much longer to finish off a pass.
I'll close with a side-note from Curt which is of possible
interest to sites with source licenses:
> Another thing I have done is to modify format to use a pattern, then xor the
> pattern with 1, and use that as the next pattern. Makes it easier to find
> bits stuck since you always have an exact complement for the second pattern.
> This finds a ***lot*** more bad spots than Sun format does. I had a drive
> that 150 passes of Sun format found 11 bad spots on. My hacked version
> found over 150 bads in the same number of passes. I dont have a flaw map
> for this drive, so I have no idea how many the drive really had...but I felt
> a lot better with finding 150 than with finding 11!
Many thanks to:
alexl@daemon.cna.tek.com (Alexander Lopez)
bit!markm@cse.ogi.edu (Mark Morrissey)
curt@ecn.purdue.edu (Curt Freeland)
david@elroy.Jpl.Nasa.Gov (David Robinson)
fabrice@sj.ate.slb.com (Fabrice Le Metayer)
pallen@atc.boeing.com (Paul Allen)
perw@holtec.se (Per Westerlund)
John
-- John Desrochers Mitel Canada john@Software.Mitel.COM
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:12 CDT