Alarmingly high Load_Cycle_Count - Have you checked?
Hi friends,
I recently happened to do: Code:
smartctl -d ata -a /dev/sda|grep Load_Cycle_Count This seems to be a bug in acpi (or should we call it some really sloppy coding?), 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: Code:
#!/bin/bash In plain words, this has gotten me annoyed. I can't believe professionals who are responsible for coding stuff on linux have done something this irresponsible and have released it to the public without testing and knowing the outcomes. Windows is bad enough, but this is like suicide. Suggestions and workarounds welcome. |
Actually, the drive manufacturer's own power saving rules will cause this. Not all distro's set a spin down time, so the drive's defaults are used, which are pretty aggressive (128 usually).
This is mine, and for the first year I had this system, I didn't have anything set for hard drive power saving, I used the manufacturer's default. The manufacturer says the drive lasts 600,000. Code:
193 Load_Cycle_Count 0x0012 050 050 000 Old_age Always - 500743 |
So which distros do set a spin down time? Fedora doesn't if its true, right?
|
You can check to see what it is set at with something like:
Code:
hdparm -I /dev/sda|grep 'Advanced power management level:' |
The thing is, how can this problem be solved? If an OS can indeed set these levels, it means that windows was behaving normally with the hardware - this number shot up only after I installed linux. So, if it is indeed hardware that is responsible, my question will again be simple - what the hell were the manufacturers thinking? Do they want people to run only Vista which overrides the BIOS settings? Is this a plan to make people running different operating systems suffer? Moreover, is this something that has been done my MS? :P
It all may seem a little wild to listen to, but my mind is so full of questions right now! Damn!! Ah, back to the main question: how can this problem be solved? |
I think the manufacturers just set the default at medium, 128 is right in the middle of 0 and 255. Yes, Windows usually sets a higher number when it boots, I don't use it so I'm not sure what it is. That can also cause problem, if the laptop is jarred without the heads parked it can cause a lot of damage to the disk.
By setting 'hdparm -B (0-255) /dev/sda', you are fixing this "problem". The higher you set it, the less often it is going to park the heads, set 255 and it will never park the heads. My Load_Cycle_Count has gone up 2000 since I last posted, my power management level is still 128, I'm not worried, I have a 3 year warranty left on the disk and a full backup. |
Quote:
|
I'm actually curious to see how real that 600,000 load cycle lifetime is. Like I said, if it worries you, disable head parking all together and risk damaging the drive in other ways. Laptop drives are some of the least reliable things in the computer world, you should never rely on them, it's the nature of the beast. The only way to avoid it is go solid state, then you will be worrying about how many write cycles you theoretically have left.
|
Hmmm... I see. But what concerns me here is how can acpi be modified to combat this problem? Like, now, even when I've added some code to /etc/init.d/acpid , I'm having to restart the daemon everytime I resume from standby, switch to battery or switch back to AC. And in plain words that is neither intellectually stimulating nor fun. You forget it once, and your hard drive gets overloaded.
The thing is, how can I modify the acpi code to do away with this problem? Is there a way to do that? |
You'll have to modify whatever scripts your distro used for suspend/hibernation. My distro used pm-utils, I could add a hook that restarts acpid on resume if I had this problem, but acpid always resumes fine for me.
This isn't really an acpi problem, as acpi has no control over this function of the hard drive. |
All times are GMT -5. The time now is 06:06 PM. |