From owner-freebsd-stable@FreeBSD.ORG Sat Aug 20 19:17:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7EF61065672 for ; Sat, 20 Aug 2011 19:17:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id BC2748FC15 for ; Sat, 20 Aug 2011 19:17:31 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta13.emeryville.ca.mail.comcast.net with comcast id NjED1h0011bwxycADjHTjs; Sat, 20 Aug 2011 19:17:27 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id NjGv1h0061t3BNj8ejGxAZ; Sat, 20 Aug 2011 19:16:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B2DDA102C1A; Sat, 20 Aug 2011 12:17:26 -0700 (PDT) Date: Sat, 20 Aug 2011 12:17:26 -0700 From: Jeremy Chadwick To: Alex Samorukov Message-ID: <20110820191726.GA39027@icarus.home.lan> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> <4E50003D.30803@os2.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E50003D.30803@os2.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 19:17:31 -0000 On Sat, Aug 20, 2011 at 08:43:09PM +0200, Alex Samorukov wrote: > > >"The SMART tests you did didn't really amount to anything; no surprise. > >short and long tests usually do not test the surface of the disk. There > >are some drives which do it on a long test, but as I said before, > >everything varies from drive to drive." > > > It is not correct statement, sorry. Long test trying to read all the > data from surface (and doing some other things). > > // one of the smartmontools developers and sysutils/smartmontools > maintainer. That's great, but too bad it's generally not true in practise. Dan's long scan on his site proves it, and I've dealt with this situation myself many times over. SMART long tests *may* do a surface scan, but in most cases they just seem to do something that's similar to "short" but over a longer period of time. Furthermore, some which *do* do a surface scan on a "long" test don't always report LBA failures in the self-test log. I've personally seen this happen on Western Digital disks (model strings are unknown, I'm certain I've rid myself of those drives). Firmware bug/quirk? Possibly, but at the end of the day it doesn't matter -- it means the end-user has wasted 2-3 hours for something that tests OK yet we know for a fact isn't OK. I *have* seen a drive do a surface scan on a "long" test and report LBAs it couldn't read, but as I said, it's rare and varies from vendor to vendor, drive to drive, and firmware to firmware. When it happened I was very, very surprised (and delighted). The only thing I can trust 100% of the time when it comes to surface scans is SMART selective scans (if available, which again the OP's drive does not offer this), or using dd or a read-per-LBA on the OS level (which works everywhere). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |