<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The reason I said the discs were 'faulty' was because on running
smartctrl on both discs it terminated with an error, it reported
Read Failures consistently for the same LBA_of_first_error <u>not</u>
because of the Load_Cycle_count value (I mentioned this in my first
post to this thread and the reason the discs have been returned to
the supplier). I was just reporting my Load_Cycle_count_values
since this seemed to be a direction the thread was going and the
info might be useful.<br>
<div class="moz-signature"><br>
</div>
<br>
On 07/01/12 17:28, Simon Hobson wrote:
<blockquote cite="mid:p06240826cb2e2e8965bb@simon.thehobsons.co.uk"
type="cite">
<pre wrap="">PJR wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My two WDC WD10EARX-00N0YB0 (possibly faulty) drives have:
9 Power_on_Hours 190
193 Load_Cycle_Count 1064
9 Power_on_Hours 175
193 Load_Cycle_Count 1064
I assume, if they weren't faulty this is not good?
</pre>
</blockquote>
<pre wrap="">
Why faulty ?
The whole essence of this thread is that these drives have (by
default) very aggressive power saving. If idle for just 8 seconds
they will unload the heads - which I assume means moving them to a
safe zone on the disk and lifting them. After this, I suspect there's
another fairly short timer before they also spin down the drive.
On a typical Unix [like] system, there are frequent disk accesses -
checking this, logging that, etc, etc. So what tends to happen is the
drive goes idle, unloads the heads, the system accesses it so it
loads the heads, rinse and repeat often. So the Load_Cycle_Count
which counts these will increment quite rapidly.
The suggestion is that it better to increase the timeout, so under
normal use they won't unload the heads very often, if at all.
Say you accessed the drive every 30 seconds. On each access, the
drive would load the heads, do the access, then 8 seconds later
unload the heads again. So that's 120 load cycles per hours, or 2880
load cycles per day !
Increase the timeout to a minute or two, and under the same scenario
you'd probably have none.
Which reminds me I need to twiddle with some drives I use for
backups. I bought a SATA card for the old Mac I use to run
Retrospect, but kept getting some rather oddball errors, kernel
panics, and so on. I thought the card might be faulty, but then
twigged ...
I've done a cron job which every minute updates a file on any of the
backup disks that are mounted - which prevents the drive going to
sleep and spinning down. I suspect the load cycle count will be going
up quite nicely on them - up to 1440 per day while the drive isn't
actually being accessed by the backup software.
What was happening was that the backup software accesses the drive to
see what it is, then goes off to find a client - it then scans the
client, does a bit of thinking to decide what files need copying, and
then starts copying files by which time the drive has got bored and
spun down resulting in an error and/or kernel panic.
</pre>
</blockquote>
</body>
</html>