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:

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
freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"