THANKS TO:
Casper Dik <casper@holland.Sun.COM>
alevin@ltcm.com (Avi J. Levin)
Mr T Crummey <tom@sees.bangor.ac.uk>
Jens Fischer <jefi@kat.ina.de>
fletch@ttmc.com (Fletcher B. Cocquyt)
ANSWER:
Everyone pointed out that parity errors and bad block are generally
due to hardware problems (cables, terminators, etc.) and could not
occur at the filesystem level. Fletcher Cocquyt pointed me to a
firmware patch for ST32550 and that seems to be the source of my
problem!
ORIGINAL POST:
> Hi,
>
> I've got a client that bought a bunch of SEAGATE (ST32550 2.1 GB) drives
> and they've been giving him a lot of problems. He has gotten SCSI parity
> errors and fsck keeps complaining about an inordinate number of bad blocks. In> the Sun Manager's FAQ I saw this one item:
>
> 3.29) I have all kinds of problems with SCSI disks under Solaris 2.x
> They worked fine under SunOS 4.x.
>
> and says to turn off command queuing as a fix. I was wondering if the
> situation I've described falls under the "all kinds of problems with SCSI
> disks ... " blanket?
>
> The other thing I suspect he 'newfs'ed the regular devices rather than the
> *raw* devices (ex: newfs /dev/dsk/c0t1d0s0) ... I have no idea if this
> could be part, if not all, of the problems.
>
> TIA,
>
> --raju
RESPONSES:
----------------------------------------------------------------------------
From: Casper Dik <casper@holland.Sun.COM>
Typically, parity errors would not be the result of that.
Check cabling an such, it's really important.
Casper
----------------------------------------------------------------------------
From: alevin@ltcm.com (Avi J. Levin)
The SCSI errors you describe are more low level than the filesystem -
newfs could not have caused them (and will not make a difference if you
specifiy raw or cooked device).
One possibility is that he has a bunch of bad disks that came in a batch,
I had this happen to me once with 2.1 Seagate drives with 12 failures
out of 8 disks from a single manufacturer. AT the time I had
changed the firmware for the drives, and this did nothing. They were
simply defective. The manufacturer/VAR claimed that this particular
drive had a problem that only manifests itself after about 3 months of
use - so that it passed all their burn-ins.
Another possibility is that your client is running something <2.5.
Specifically, 2.3 had MANY SCSI driver problems, and I believe there
were a few patches. But the problems persisted. 2.5 seems a lot more
stable in my experience.
---Avi---
----------------------------------------------------------------------------
From: Mr T Crummey <tom@sees.bangor.ac.uk>
Hello,
Bad blocks are always due to hardware problems. Check the usual litany of
cables, SCSI bus length (less than 2metres) and termination. Check the
firmware revision on the drive. Some earlier Seagates give trouble.
-- Tom.---------------------------------------------------------------------------- From: Jens Fischer <jefi@kat.ina.de>
Hi Raju,
Seagate ST32550 surely have no problems with tagged command queuing. We use about 100 of them without problems, even the internal disks of our Ultras are of this type.
The newfs command is no problem either, newfs would complain if there would be problems (Only in earlier versions, with partitions > 2 GB).
I would suspect cabling or termination problems, the parity errors are pointing to that. A damage to the SCSI interface of the drive or the machine itself theoreticaly could also cause such problems, but normaly in this case it would not work at all.
Hope that helps
Kind Regards - Jens Fischer
---------------------------------------------------------------------------- From: fletch@ttmc.com (Fletcher B. Cocquyt)
Another thing you can do is apply patch 103451 which is a firmware upgrade for that model disk.
----------------------------------------------------------------------------
Raju Krishnamurthy - Senior Software Engineer ____________________________________________________
E C O l o g i c C o r p o r a t i o n http://www.ecologic.net
raju@ecologic.net 19 Eye Street, N.W. Washington, DC 20001
v. 202.218.4100 f. 202.842.5088
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:18 CDT