From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 9 18:30:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9DD916A4ED for ; Sat, 9 Oct 2004 18:30:36 +0000 (GMT) Received: from beck.quonix.net (beck.quonix.net [146.145.66.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DFEE43D1F for ; Sat, 9 Oct 2004 18:30:36 +0000 (GMT) (envelope-from john@essenz.com) Received: from [192.168.1.100] (pool-141-158-247-68.phil.east.verizon.net [141.158.247.68]) by beck.quonix.net (8.12.11/8.12.11) with ESMTP id i99IUXxv015417 for ; Sat, 9 Oct 2004 14:30:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20041009044403.P39589-100000@mxb.saturn-tech.com> References: <20041009044403.P39589-100000@mxb.saturn-tech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D27BFB8-1A20-11D9-883D-0003933DDCFA@essenz.com> Content-Transfer-Encoding: 7bit From: John Von Essen Date: Sat, 9 Oct 2004 14:21:34 -0400 To: " " X-Mailer: Apple Mail (2.619) X-SpamAssassin-2.64-Score: 0.5/6 RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL X-MimeDefang-2.44: beck.quonix.net X-Scanned-By: MIMEDefang 2.44 Subject: Re: hacking SCO.... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2004 18:30:37 -0000 I was able to use the badtrk utility in SCO to identify bad blocks and put them in the bad block table. The SCSI card is an old Adaptec, AIC-7880 and I believe it does not support automatic bad block detection/redirection. This disk came from a spares kits, so even though it is "new" and never used, it is still 5-6 years old. There were 6 bad blocks, once they were put in the bad block table, everything was fine. Is sformat the freebsd equivalent of the badtrk utility. I have always used Ultra2 LVD SCSI and higher on FreeBSD and have never had this issue of bad blocks. Is that because those newer SCSI disks and controllers have better ECC handling and take care of the bad blocks internally without notifying the user? -john On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: > > On Fri, 8 Oct 2004, Sergey Babkin wrote: > >> Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries >> to re-map the bad sectors (it tries to preserve data during this too, >> unless the sector is completely unreadable). > > The verify commands issued by the BIOS are virtually useless compared > to > the type of tests done my sformat. If you enable automatic read > re-allocation, it is almost the same as simply reading your whole disk > with dd. > >>> I do the full 14 pattern tests before I put a SCSI disk in service. >> >> When a disk starts losing blocks like this, usually they only multiply >> over time. The best thing you can do is replace the disk and >> move the data before you lost more of it. > > NO! Not necessarily! > > If a disk has simply grown a few new defects since it was new, it does > not > necessarily mean it is going to die. I have many disks that had minor > bad > spots on them that weren't even always found by the factory format > routines, or had appeared since (due to transport, debris in the HDA, > poor > holding power for the magnetic fields in some area, etc). If the drive > passes through a few full patern tests without problems and doesn't > continue to grow new defects, it is likely just fine. > > I've got all kinds of old SCSI disks that were 'discarded' due to > errors. > Only a couple are truly dead... the rest have been running for years > with > no problems after making a real grown defect list from the pattern > tests. > > This is something I learned many many years ago when running my old > Miniscribe 3650s on a Perstor high density controller. It formated the > drives to 31 sectors per track instead of 17. Hard on the disks, and > the > media, but a good drive, after being properly tested, would run > flawlessly > for years being hammered 24/7 on BBS machines. Got 78 megs per drive > instead of 42.whatever it was. :) > > Later...... > > >