Chris, 

You're right that people should, by and large, be going off of "thresh,
value, and worst".  And, no, it doesn't hurt to look at the count, if
the count on your particular system is accurate -- in fact, it can be
quite helpful when checking to see if your system has stopped
parking/unparking unnecessarily, or in counting just how often your
system *is* undergoing a load/unload cycle.  However, the raw value (the
count at the end of the list) is not nearly the reliable life-expectancy
counter that thresh/value are (assuming you know the starting/high value
of "value/worst").

> -       3037783573354
> 
> That number is over 3 *trillion*, which, for a 14 month old laptop is
> physically impossible, it would have to be unparking the heads 80,000
> times *a second*. Again, this is physically impossible.

Obviously, yours is one case that fits the (documented) circumstance
where the value is not printed out accurately for your hard disk.  There
are methods to reformat this output so that it displays accurately.  You
have probably read up on this, but mistook the meaning.  If you haven't
read up on it, you can, at:
http://smartmontools.sourceforge.net/

My counter goes up by one every time the HD parks and unparks.  My
counter is at 171,983.  My drive is rated for 600,000 parks.  My thresh
is zero, and my value/worst have a starting value of 200, and are at
143.  The ratios in relation to each other are accurate.  

I have not changed anything regarding laptop mode on this system.  By
default, laptop mode is not on in Ubuntu.  Likewise, laptop mode is not
on on my system, and never has been.  Laptop mode is not this issue.
This has been established already.  I myself thought Ubuntu came with
Laptop mode enabled, but have learned differently (and that it wasn't
enabled on my system, either) along the way.

Over a quarter of my HD life is gone, and I've had this laptop for about
half a year.  That puts the usable lifetime just under two years.  Last
I checked, hard disks did not have a life expectancy of less than 2
years.  In fact, my Western Digital Scorpio has a MFG warranty of 3
years.  I doubt they expect it to die within that time.  5 years gives
them a nice margin of error, but four years would even do it for them, I
imagine.

> So, to be absolutely, entirely clear about this, Ubuntu is not killing
> my hard disk, no matter what Slashdot and misinformed blog posts claim.

To be absolutely clear about this, I would appreciate it if you had a
greater understanding of the situation before claiming that there is no
problem.  There very definitely is a problem, the problem has existed
for a very long time, and it does indeed cause hard drives to break.  I
have been with Ubuntu for a long time, and I intend to stay with Ubuntu.
But this problem must be acknowledged and dealt with, and
misinformation, albeit with good intent, does not help that.  A review
of the posted information could have provided you with enough
information to know that there are valid cases here.

> To everyone who has commented on this bug with wild claims about how
> much their Load_Cycle_Count value is increasing, go back to smartctl's
> output and check the VALUE and THRESH columns and I am entirely
> confident you will find that your drive is well within expected
> lifespan.

You are incorrect.  My drive is well outside of its expected lifespan,
if things continue as they currently are going.  That is, if you take
the manufacturer's warranty as its expected lifespan, then my disk's
expected lifespan is less than 2/3 of that.  If, however, you assume
that Western Digital didn't expect that their disks would die as *soon*
as the warranty was expired, and tack an additional year onto its life
beyond the manufacturer's warranty, then my disk's expected lifespan is
less than 1/2 of that.

> The reason is because the RAW_VALUE column is entirely manufacturer
> specific. 

Yes, it is.  However, it is often accurate.  Just because there is the
potential for information to be read incorrectly does not mean that in
all cases that information is being read incorrectly.  In fact, there
are many documented cases here as well as in the duplicates, and in the
bug this was once incorrectly assigned as a duplicate of, that are
valid.

-Brian