Alarmingly high Load_Cycle_Count - Have you checked?

[ashesh0326]

Hi friends,

I recently happened to do:

smartctl -d ata -a /dev/sda|grep Load_Cycle_Count

I noticed that my hard drive's spin down frequency was too high - 2-3 times every 30 seconds or so - which is an invitation for hard drive failure.

This seems to be a bug in acpi/hardware and it will kill hard drives prematurely, and all of us know how scary hard drive crashes can be.

So, I went through something that could've been a workaround but it hardly helped. (Scripts in /etc/acpi/resume.d/ never get executed, I don't know what this guy was thinking)

The only thing that's helping is adding the code:

#!/bin/bash
if on_ac_power; then
  # on AC so don't do any head parking
  hdparm -B 254 /dev/sda
  hdparm -B 255 /dev/sda
else
  # either on battery or power status could not be determined
  # so quickly park the head to protect the disk
  hdparm -B 128 /dev/sda
fi

to /etc/init.d/acpid and restarting as soon as you resume or switch to battery (or vice versa).

I also experimented with windows and found the count stopped increasing on windows - which shows that windows overrides the BIOS settings. The problem here should be with the hardware and with ACPI which is using the default settings of the BIOS.

So, what were the hardware manufacturers thinking? Is this another move to discourage linux and promote microsoft? What is this?

Suggestions and workarounds welcome.

[Hlingler]

I'm curious to know your full system specs, especially hardware/HDD make/model, since I have seen no such issue, and this issue may be specific to your PC and/or HDD model(s).

Thanx and Regards,
V

[ashesh0326]

Originally Posted by Hlingler

I'm curious to know your full system specs, especially hardware/HDD make/model, since I have seen no such issue, and this issue may be specific to your PC and/or HDD model(s).

Thanx and Regards,
V

Thank you for your reply. I'm on a Compaq Presario V3000/AMD Turion 2.20/120 GB SATA/1.5 GB RAM/Nvidia GeForce Go 6150.

The Load_Cycle_Count increases too rapidly if hdparm -B254 /dev/sda is not done (right after resuming or switching to battery or vice versa).
Can't there be a permanent solution? I've also come across this: https://wiki.ubuntu.com/DanielHahler/Bug59695 which shows that this is pretty common and is happening with most laptops out there.

smartctl -i /dev/sda
smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Momentus 5400.3
Device Model:     ST9120822AS
Serial Number:    5LZ3GCWF
Firmware Version: 3.BHD
User Capacity:    120,034,123,776 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Thu Apr 24 22:37:13 2008 IST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

[Hlingler]

The hdparm utility has been somewhat "crippled" by the switch to libata: many settings don't work (e.g., the "-c" and "-d" switches). Also, there have been some recent updates to hdparm that have not made it into the F8 repos. Try this updated version for F8-i386 (hdparm-8.6-1.fc8.micron.i386.rpm): http://www.4shared.com/file/43084138...ified=32bc7e80

As usual, the required disclaimer: this software is provided as-is, in the hopes that it will be useful, but without warrantee of any kind, including fitness for any particular purpose. Use it at your own risk. Not GPG-signed. Maybe it'll help.

V

EDIT: For reference, here's a summary of the changelog since the "stock" F8 version 7.7:

hdparm-8.6
        - add partition safeguards to r/w sector and make_bad_sector
hdparm-8.5
        - fix u8->u16 bug in security commands for all of 8.x series, Christian Franke
        - try and quiet errors from flush_buffer_cache()
hdparm-8.4
        - oops: v8.3 broke --write-sector.  Fix it again.
hdparm-8.3
        - fixed -i display for udma6
        - try and exit with errno on fail paths, from Ladislav Michnovic
hdparm-8.2
        - clear feat register for safety with SET_MAX_ADDRESS command
        - add note to manpage regarding possible -N transient failures
        - IDE_TASKFILE bug fixes and cleanups: works with old IDE driver now
        - fix misreporting of dma modes on some SATA-ATAPI bridged drives
hdparm-8.1
        - fixed -U parameter bug
        - added ATA8 minor revision info to -I, courtesy of chrfranke
        - added WorldWideNumber to -I, courtesy of Raksac
hdparm-8.0
        - added --make-bad-sector to deliberately create a media error
        - added --write-sector (aka. --repair-sector) to repair a media error
        - added --read-sector to test for a media error
        - Makefile dependency tweaks
        - added -N (get/set max address/HPA) flag, courtesy of Jakub Bogusz
        - fixed LBAsects output from -i to use LBA48 values when available
        - fixed alternate opcode for SLEEPNOW
        - lots of changes/fixes to sgio.c to support more commands
        - add detection of buggy Sandisk 16MB CF card
        - fixed tf_to_lba() bug, courtesy of Jakub Bogusz

[thunderogg]

Originally Posted by ashesh0326

Hi friends,

I recently happened to do:

smartctl -d ata -a /dev/sda|grep Load_Cycle_Count

I noticed that my hard drive's spin down frequency was too high - 2-3 times every 30 seconds or so - which is an invitation for hard drive failure.

This seems to be a bug in acpi/hardware and it will kill hard drives prematurely, and all of us know how scary hard drive crashes can be.

So, I went through something that could've been a workaround but it hardly helped. (Scripts in /etc/acpi/resume.d/ never get executed, I don't know what this guy was thinking)

The only thing that's helping is adding the code:

#!/bin/bash
if on_ac_power; then
  # on AC so don't do any head parking
  hdparm -B 254 /dev/sda
  hdparm -B 255 /dev/sda
else
  # either on battery or power status could not be determined
  # so quickly park the head to protect the disk
  hdparm -B 128 /dev/sda
fi

to /etc/init.d/acpid and restarting as soon as you resume or switch to battery (or vice versa).

I also experimented with windows and found the count stopped increasing on windows - which shows that windows overrides the BIOS settings. The problem here should be with the hardware and with ACPI which is using the default settings of the BIOS.

So, what were the hardware manufacturers thinking? Is this another move to discourage linux and promote microsoft? What is this?

Suggestions and workarounds welcome.

Thank you very much for the fix. It's a bit rought, but it works. However, I don't see why you first put it to 254 then to 255. As far as I understand you only need one of them. Either allow head parking, but not so often (254), or turn it off totally (255).

[ashesh0326]

You're welcome, and I'm sorry I ignored that. I just looked here: http://ubuntuforums.org/showpost.php...0&postcount=26
for the workaround. Its not mine. I've used the same code with 254, and it does the job here. I just overlooked changing it while posting it here.

[thunderogg]

Originally Posted by ashesh0326

You're welcome, and I'm sorry I ignored that. I just looked here: http://ubuntuforums.org/showpost.php...0&postcount=26
for the workaround. Its not mine. I've used the same code with 254, and it does the job here. I just overlooked changing it while posting it here.

There are a lot written about this subject. Here are two links:

http://ubuntudemon.wordpress.com/200...-are-affected/
http://www.advogato.org/person/mjg59/diary/82.html

I hope it can be of use for the Fedora notebook users who want to save their harddiskdrives.

[thunderogg]

Hm, the fix doesn't work with suspend to RAM, and not with hibernate either!!
There must be a way of running the script after suspend and hibernate.

[ashesh0326]

Originally Posted by thunderogg

Hm, the fix doesn't work with suspend to RAM, and not with hibernate either!!
There must be a way of running the script after suspend and hibernate.

Yes, there are issues with suspend to RAM and hibernate and even I have to invoke acpid after every resume by doing /etc/init.d/acpid - which again sets the spin down frequency and does not let the BIOS decide what to do.
I tried placing the script in a .sh file under events under the names resume.sh, on_ac.sh, etc. but acpid failed to parse them on startup. Even I'd like something automatic that saved me from the pain of doing it over and over again after every suspend/resume.

[thunderogg]

Isn't this something pm-utils should handle? I experimented by putting the script in /usr/lib/pm-utils/sleep.d/99video, in the resume video_function. I know it's not the right place, but when the video is resumed all other services are up so it shouldn't cause any problem. Anyway, it works with suspend to RAM, but not with hibernate.

[thunderogg]

Now it works both with suspend and hibernate. I put the script in /usr/lib/pm-utils/sleep.d/99video. but in the last part:

case "$1" in
     resume)
          resume_video
          SCRIPT
          ;;
     thaw)
          if [ "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then
              resume_video
          fi
          SCRIPT
          ;;
esac

It's not beautiful, but it works for me. Hope it works for you too. I think there should be an option to put into the HAL configuration for this.

[fhubers]

If the number doesn't seem to be incrementing does that mean I am okay? I seem to keep getting this response:

193 Load_Cycle_Count        0x0012   090   090   000    Old_age   Always       -       102625

my hard drive info is:

=== START OF INFORMATION SECTION ===
Model Family:     Hitachi Travelstar 7K100
Device Model:     HTS721080G9AT00
Serial Number:    MPC411Y4G2BGHC
Firmware Version: MC4OA40M
User Capacity:    80,026,361,856 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   6
ATA Standard is:  ATA/ATAPI-6 T13 1410D revision 3a
Local Time is:    Thu May  8 20:04:41 2008 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

This is new to me - appreciate the insights!

[thunderogg]

Originally Posted by fhubers

If the number doesn't seem to be incrementing does that mean I am okay? I seem to keep getting this response:

193 Load_Cycle_Count        0x0012   090   090   000    Old_age   Always       -       102625

Keep an eye on the Always value. You have now 102625. Some say 600000 is what a drive is designed to support. Others say 200000. My drive had 50000 after just two months. I keeps on parking every minute! That would mean it would last a year. Well, these are theoretical numbers, but ...

Oh, between each power down (power off, suspend to RAM, or hibernate), the value should increase at least one step!

[thunderogg]

There is an other side of the problem, the temperature of the harddisk. They say the drive is parked to save energy, but it's also to bring down the temperature. So if you disable the parking, you should monitor the the temperature of you harddisk. Install hdtemp, then you can use gnome sensors to keep an eye on the temp.

[ashesh0326]

If the Load_Cycle_Count doesn't increase then its for sure that you're not facing this problem. Remember that this is not a bug with acpi or the kernel, there is something wrong with the BIOS. There are some BIOSes out there that set a very agressive power management policy and hence spin down the hard drive too frequently - I don't know what the developers were thinking.

What linux doesn't do is set a custom spin down frequency for the hard drive - it accepts what the BIOS is offering. hdparm basically helps in overriding the BIOS settings. Phoenix BIOSes suffer from this problem.