From owner-freebsd-stable@FreeBSD.ORG Tue Oct 28 13:10:21 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 943A01065676; Tue, 28 Oct 2008 13:10:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 100228FC1F; Tue, 28 Oct 2008 13:10:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3FFFB744175; Tue, 28 Oct 2008 15:10:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5oeeeuBFuEo; Tue, 28 Oct 2008 15:10:16 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 816EA744005; Tue, 28 Oct 2008 15:10:15 +0200 (EET) Message-ID: <49070F36.8090606@icyb.net.ua> Date: Tue, 28 Oct 2008 15:10:14 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: Jeremy Chadwick References: <4905951B.2050602@sh.cvut.cz> <20081027160828.GA24496@icarus.home.lan> <4905F8BB.3080302@sh.cvut.cz> <20081027175337.GA27175@icarus.home.lan> <20081027191028.GA28688@icarus.home.lan> <20081027195949.GA29641@icarus.home.lan> In-Reply-To: <20081027195949.GA29641@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, martinko Subject: Re: Short SMART check causes disk op timeouts 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, 28 Oct 2008 13:10:21 -0000 on 27/10/2008 21:59 Jeremy Chadwick said the following: > On Mon, Oct 27, 2008 at 08:50:44PM +0100, martinko wrote: >> Jeremy Chadwick wrote: >>> On Mon, Oct 27, 2008 at 07:52:01PM +0100, martinko wrote: >>>> Jeremy Chadwick wrote: >>>>>>>> Now, does the timeout cause loss of any data? Is there anything besides >>>>>>>> disabling the testing that I can do about it? >>>>>>> Do you understand what short and long offline tests actually do and what >>>>>>> they're used for? :-) If so, you'd know that running them periodically >>>>>>> is more or less silly (IMHO). >>>>>> I do not, not completely :) I think I have just copied the settings from >>>>>> somewhere and only just tweaked it a bit whenever I have added a disk. >>>>> Let me know if you figure out who or what online resource solicited >>>>> adding daily short/long tests, as I'd like to talk to them about their >>>>> decision. I have a feeling whoever thought it up felt that the tests >>>>> were performing entire sector scans of the entire disk, which is simply >>>>> not the case. >>>>> >>>> Hallo, >>>> >>>> Reading this thread I checked my config to find this: ;-) >>>> >>>> #/dev/ad0 -a -n standby,q -o on -S on -s (S/../.././02|L/../../7/03) >>>> -m root # ++ 2006-11-03 mato >>>> /dev/ad0 -a -o on -S on -s (S/../.././02|L/../../7/03) -m root # ++ >>>> 2006-11-03 mato >>>> >>>> I believe I came up with the settings after reading manual page / >>>> documentation of the tool. >>> Can you explain why you're doing this? So far no one's provided a >>> reason *why* they're doing short and long offline scans on a daily >>> basis. I'm under the impression the conclusion was reached like this: >>> "man smartd.conf ... oh, -s, a neat thing, let's enable it". >>> >>> There are negative repercussions to doing tests of this nature at such >>> regular intervals. Once-a-week is borderline acceptable; once a month >>> would be quite reasonable. I'd love to know what kind of affect daily >>> tests have on MTBF; I can imagine it's reached much sooner with this. >>> >>> The main point of smartd is to monitor SMART attribute changes. If >>> you're concerned about the health of your hard disk, you should be >>> looking at your logs and not relying on things like automatic short/long >>> tests. Most SMART attributes are updated immediately and not during an >>> offline test, and all of those attribute changes will be logged. >>> >> You asked Miroslav about source of his configuration. And as it is very >> similar to mine I think we both have it from smartd documentation. Where >> else to look for information? It's a usual source. So if you think it's >> wrong please contact the authors, we're obviously just users. >> Thanks. > > I'm not asking *where* you got the information from (we know where you > and others got it from: the documentation). I'm asking you *why* you > enabled what you did, because this is not something smartd.conf enables > by default (the example is commented out). > > If you *really* want me to talk to Bruce about this, I can/will, but I'm > left with the impression that the example in smartd.conf is there to > show people the syntactical usage of -o, and not to advocate its usage. > >> PS: Btw, long offline scan is scheduled on weekly basis, not daily. If >> it's good or not I do not know. > > The OP's long scan is also scheduled on a weekly basis (every Sunday), > but his short scan trumps it. > > Folks, the point I'm trying to make here is that daily -- and even > weekly -- SMART offline tests are unnecessary. If you're that concerned > about your disk health, you should be looking at your syslog logs for > attribute changes that indicate drive issues. Performing SMART offline > tests at regular intervals like this does very little other than > increase wear/tear on drive components (not necessarily the physical > platters/heads; there are many pieces to a hard disk. :-) ) BTW, I am not entirely sure what Bruce you mentioned above - probably I missed something, but I found this post: http://article.gmane.org/gmane.linux.utilities.smartmontools/1443 This was a long time ago, and it really warns about the same balance that you do, but it can hint at "source of authority" for all the configs around. -- Andriy Gapon