From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 19:50:50 2008 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 E20251065677 for ; Wed, 27 Feb 2008 19:50:50 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by mx1.freebsd.org (Postfix) with ESMTP id 8445A8FC31 for ; Wed, 27 Feb 2008 19:50:50 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) X-Trace: 50118156/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$INTERNET-ACCEPTED/None/62.31.10.181 X-SBRS: None X-RemoteIP: 62.31.10.181 X-IP-MAIL-FROM: xfb52@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOtGxUc+Hwq1/2dsb2JhbAAIrgs X-IP-Direction: OUT Received: from 62-31-10-181.cable.ubr05.edin.blueyonder.co.uk (HELO [192.168.23.2]) ([62.31.10.181]) by smtp.pipex.tiscali.co.uk with ESMTP; 27 Feb 2008 19:21:02 +0000 Message-ID: <47C5B818.9090103@dial.pipex.com> Date: Wed, 27 Feb 2008 19:20:56 +0000 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.13) Gecko/20061205 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hurd References: <47C52948.2070500@sasktel.net> <20080227121129.GA76419@eos.sc1.parodius.com> <47C5ACD0.8000009@sasktel.net> In-Reply-To: <47C5ACD0.8000009@sasktel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE 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: Wed, 27 Feb 2008 19:50:51 -0000 Stephen Hurd wrote: > Jeremy Chadwick wrote: > >>> SMART Attributes Data Structure revision number: 16 >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE >>> UPDATED WHEN_FAILED RAW_VALUE >>> 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail >>> Always - 4 >> >> This shows you've had 4 reallocated sectors, meaning your disk does in >> fact have bad blocks. In 90% of the cases out there, bad blocks >> continue to "grow" over time, due to whatever reason (I remember reading >> an article explaining it, but I can't for the life of me find the URL). > > > This is unusual now? I've always "known" that a small number of bad > blocks is normal. Time to readjust my knowledge again? I have bought disks where the value of Reallocated_Sector_Ct was not 0, at least by the time I looked at it with smartctl. Nothing bad has happened to those disks in several years (hope that's not tempting fate). I have always assumed that what matters is when this value *changes*. If it's not changing, who cares? smartd will monitor disks and email you when certain attributes change (e.g. Pre-fail attributes like Reallocated_Sector_Ct). If it changed, it would mean that an attempt to write data had failed and that reallocation had happened. e.g. from smartd.conf /dev/ad4 -o on -S on -a -m root -M daily If your Current_Pending_Sector were non-zero you'd be in trouble, I believe. 0.02, pinch of salt, not an expert, slippery when hot, long time since I read the specs, etc etc. --Alex