From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:31:26 2012 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 8A507106566C for ; Tue, 14 Feb 2012 20:31:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 303E88FC0A for ; Tue, 14 Feb 2012 20:31:25 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id Zo0Y1i0061ei1Bg5AwXSfp; Tue, 14 Feb 2012 20:31:26 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.westchester.pa.mail.comcast.net with comcast id ZwXQ1i00f1t3BNj3kwXQuN; Tue, 14 Feb 2012 20:31:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DA03102C1E; Tue, 14 Feb 2012 12:31:23 -0800 (PST) Date: Tue, 14 Feb 2012 12:31:23 -0800 From: Jeremy Chadwick To: Oscar Prieto Message-ID: <20120214203123.GA5959@icarus.home.lan> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <4F3AB4F0.9010002@omnilan.de> <20120214205143.2a6b9c87@zelda.sugioarto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Martin Sugioarto , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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: Tue, 14 Feb 2012 20:31:26 -0000 On Tue, Feb 14, 2012 at 09:19:02PM +0100, Oscar Prieto wrote: > Thank you Jeremy, i'm already checking your links. > > When i installed smartd i configured a daily short test and a weekly > long one for all the drives while the machine remains mostly unused, > never thought it could be a problem reading the documentation and info > around. > > # /usr/local/etc/smartd.conf > /dev/ada0 -a -o on -S on -s (S/../.././03|L/../../2/07) > /dev/ada1 -a -o on -S on -s (S/../.././04|L/../../3/07) > /dev/ada2 -a -o on -S on -s (S/../.././05|L/../../4/07) > /dev/ada3 -a -o on -S on -s (S/../.././06|L/../../5/07) The problem is that, quite honestly, these do you zero good. All it does is make a mess (per se) of the SMART self-test log. Take for example your situation with ada3: smartd(8) told you that the number of pending sectors increased to 5, and uncorrected increased to 1. That's really all you need to know at that point. If you want to know the LBA numbers which are problematic, you can manually intervene. The point is: the drive itself is going to notice problematic or bad sectors quicker than periodic short or long or surface scan tests will. Let the drive do its thing normally and only use SMART tests when there's indication something is wrong. > I'll remove the checks, do you advice for removing the daemon altogether? smartd(8) is useful because it keeps track of attributes which change in value and logs data to syslog (if I remember right), thus you have an exact time/date when an attribute changed. This is especially useful for things pertaining to sector/physical media problems. As such, I tend to recommend folks using smartd(8) properly tune their smartd.conf to only monitor specific attributes. This varies from drive to drive, but the key ones are things like attributes 5, 10, 11, 192, 193, 194 (if you want temperature logging), 196, 197, 198, 199, and 200. I'm speaking strictly for Western Digital disks here. The stock defaults, if I remember right, are to "monitor everything", which really doesn't work well given that so many vendors encode their RAW_VALUE fields in proprietary/vendor-specific formats. People will often monitor things like the Hardware_ECC_Recovered attribute and start "freaking out" once day when the value goes from 0 to 838938239 or something larger. Attribute data formats are not part of the ATA standard, so vendors choose to encode them. Plus, not many admins that I've run into (honest) know what that attribute actually means disk-wise (hint: it's 100% normal for sector ECC to happen at all times; magnetic media is not perfect, that's what the per-sector ECC section is for!) However: people don't understand what SMART attribute acquisition actually does behind the scenes -- it results in the disk having to read from the HPA area (not user accessible or within LBA regions), which means seeking + moving the arms to an area, reading, then reporting all of this back. Thus, it impacts I/O performance. This is why I don't use smartd(8) on any of our systems. But if I was to use it? I would have it poll maybe every 120 minutes, rather than every 30. It all depends on the system/load/etc.. I've seen people poll every 5 minutes (I think they're absolutely crazy/paranoid). Their systems, their problem. :-) Hope this helps. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |