Is SMART really that dumb?

[Chris Murphy]

On Sun, Mar 15, 2015 at 9:40 AM, Robert Nichols
<rnicholsNOSPAM at comcast.net> wrote:
> On 03/15/2015 10:23 AM, Chris Murphy wrote:
>>
>> On Sun, Mar 15, 2015 at 8:54 AM, Robert Nichols
>> <rnicholsNOSPAM at comcast.net> wrote:
>>
>>> One thing I noticed in there is:
>>>
>>>    193 Load_Cycle_Count        -O--CK   001   001   000    -    747412
>>>
>>> That drive is absolutely _killing_ itself by unloading the heads every
>>> 90 seconds or so (17421/747412 = .0233 hours/cycle).  This probably
>>> isn't related to the problem you're seeing, but you should look into
>>> what timeout setting is causing that.  It's hurting performance, too.
>>
>>
>> While it seems pathological, I'd leave it alone if the drive is being
>> used for the proper workload it was designed for. The less time the
>> heads are flying over platter surface, the better. Even though this
>> attribute value is 001 and the threshold is 000, it's not a pre-fail
>> attribute, just an age attribute. It's probably instigated at least as
>> much by something that's fsyncing every ~90 seconds like the journal
>> or rsyslog.
>
>
> At that rate, in about 5 days smartd will start reporting "FAILING NOW"
> for that attribute.

No it won't. That attribute type is old_age not pre-fail. You don't
ever get failing now reports for old_age attributes.

> The performance impact of having to wait for the
> heads to reload every 90 seconds should be noticeable.

Doubtful. The actuator can move from parked to the far side of the
platter in what, 1/10th of a second? Faster?


 The only
> advantage of _not_ having the heads flying over the platter surface is
> about 1 Watt decrease in idle power.

That's not true, there's a much higher likelihood the head hits
particles on the surface of the platter, or even touches the surface
of the platter. It can't ever do that if it's parked. You basically
have to assume the engineers are morons to 2nd guess this behavior.

-- 
Chris Murphy