SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Argh, mine is at 1,5 million after 5300 hours. I'd say, given the specs, your cycle count looks OK Dave, but failure of my hard drive is probably imminent. Disabling APM by hdparm doesn't work and the BIOS has no setting to disable it. I use LUKS encryption, so if there's corruption it may be pretty bad. I'll buy an external drive for backup. Thanks for pointing at this issue phys.
Yeah, I think mine was okay for now, but it was getting hit at 70-80 / hour vs. what I've gathered is a desired <= 15/hour. So, I figured I'd try a preventative measure.
5000/hour is crazy.
The hdparm trick worked for me as over the course of yesterday up until I made the change (maybe 5 hours of operation), my load cycle count increased by ~350. Since the change in an additional couple of hours of operation, it has increased by <10.
Curious that it did not seem to work for you. Did you make sure to add the hdparm command in rc.local or similar (since it seems the parameter gets reset at reboot). Of course, since it's tweaking a hardware parameter, the behavior could be hardware-dependent.
Curious that it did not seem to work for you. Did you make sure to add the hdparm command in rc.local or similar (since it seems the parameter gets reset at reboot).
Yes it's already there, doing it by hand in the console doesn't help. It's still around ~300 cycles per hour. The bugreport says some drives are unresponsive to disabling using hdparm. This evening I'll check whether this happens on Windows too. But the real disappointment is this stupid Phoenix BIOS. It allows you to change the boot order and system time plus a few trivial things, you can't modify many other important stuff.
H_TeXMeX_H since I'm in a desperate situation I think it would be worth the risk. The HDD will quietly sit at a corner of my room except when I make backups once in a while. Hopefully it will survive long enough.
Nothing, but no HDD can be considered a safe backup strategy. Just look at the recent seagate issue. Your drive could fail within days or weeks of purchase.
I think there are several keys to safe backup. One is that the backup media should not be running on the same machine, power supply, etc.
I use TWO external USB drives which are left powered off except when I am actually doing a backup. Eventually, I will put all the more important stuff on DVDs also.
On Windows I get around ~40-50 cycles per hour which is still too much. I haven't tried setting APM off, though. Following someone's idea in the Ubuntu bugreport page, I wrote a small script which keeps calling smartctl every 3 seconds:
Code:
#!/bin/bash
while [ 1 ]
do
smartctl -d ata -a /dev/sda | grep Load_Cycle_Count
sleep 3
done
The point is this command wakes the HD up, so it prevents head parking. Using "sleep 5" wasn't enough. It seems the drive is pretty aggressive, it will park the head in 4-5 seconds of inactivity. Since I've been running this script, the cycle count is frozen at 1529559. The temperature is 43 C which is nominal for this drive.
On Windows I get around ~40-50 cycles per hour which is still too much. I haven't tried setting APM off, though. Following someone's idea in the Ubuntu bugreport page, I wrote a small script which keeps calling smartctl every 3 seconds:
Code:
#!/bin/bash
while [ 1 ]
do
smartctl -d ata -a /dev/sda | grep Load_Cycle_Count
sleep 3
done
The point is this command wakes the HD up, so it prevents head parking. Using "sleep 5" wasn't enough. It seems the drive is pretty aggressive, it will park the head in 4-5 seconds of inactivity. Since I've been running this script, the cycle count is frozen at 1529559. The temperature is 43 C which is nominal for this drive.
You know, I think this might be the only real solution. A clever one, thanks for posting it.
Thank you, this is the link to the post where I got this idea from.
I've played with this a little bit. Using 'sync' instead of smartctl also seems to work. The nice thing is, sync can be called by ordinary users too. However I haven't compared the two for CPU usage. Also, I don't know if it's possible that there might be nothing to flush. In that case 'touch' and then 'sync' might help, assuming 'touch'ing the same file every 3 seconds doesn't pose a risk for the relevant disk sector...
On Windows I get around ~40-50 cycles per hour which is still too much. I haven't tried setting APM off, though. Following someone's idea in the Ubuntu bugreport page, I wrote a small script which keeps calling smartctl every 3 seconds:
Code:
#!/bin/bash
while [ 1 ]
do
smartctl -d ata -a /dev/sda | grep Load_Cycle_Count
sleep 3
done
The point is this command wakes the HD up, so it prevents head parking. Using "sleep 5" wasn't enough. It seems the drive is pretty aggressive, it will park the head in 4-5 seconds of inactivity. Since I've been running this script, the cycle count is frozen at 1529559. The temperature is 43 C which is nominal for this drive.
Nice and elegant solution. Also nice as a tool to test out how different 'hdparm -B xxx /dev/sda' settings are working.
Incidentally, how does one stop or kill that script once it is invoked?.
Nothing, but no HDD can be considered a safe backup strategy. Just look at the recent seagate issue. Your drive could fail within days or weeks of purchase.
Every kind of medium can fail within a few seconds.
HDD is much more durable than CD-R and DVD+-R discs (but not DVD-RAM, maybe). However, if you wish to preserve your backup over centries, carve it on a rock.
Every kind of medium can fail within a few seconds.
HDD is much more durable than CD-R and DVD+-R discs (but not DVD-RAM, maybe). However, if you wish to preserve your backup over centries, carve it on a rock.
Well, that's debatable, HDDs are susceptible to static, strong magnetic fields, and high G forces. It's also much more difficult to recover data from a bricked or dead HDD than it is from a scratched DVD or CD, especially with the methods that I said above. A HDD is also more prone to corruption, whereas a DVD+-R, once written and verified cannot be further corrupted, except by scratching it. But there are various methods to remove scratches and/or recover data as mentioned previously.
I personally have never had a DVD lose data after it has been written properly. But I've had HDDs fail and all data on them lost, unless I want to pay for expensive recovery procedures in the clean room.
However, if you wish to preserve your backup over centries, carve it on a rock.
In the 21st century you should go mobile and use clay tablets .
Jokes aside, I agree with H_TeXMeX_H that CD/DVDs are far more durable than HDD's. The magnetic surface of a HDD is very sensitive already. In addition to that, there is the risk of mechanical failure. On the other hand the material DVDs are made of is quite durable and should last for a very long time if stored in a safe place.
The corruption I said my DVDs had was actually the result of an improper DVD write. I thought I had enabled "verify written data" but it turned out I hadn't. The result was that all first level files were written correctly but anything at level 2 or higher in the directory structure had 0 size and were unreadble. I made some DVD backups yesterday and made sure they are OK this time .
I personally have never had a DVD lose data after it has been written properly. But I've had HDDs fail and all data on them lost, unless I want to pay for expensive recovery procedures in the clean room.
I meant that when both are protected properly, HDDs are usually more durable than CD/DVD recordables. CD-R and DVD+-R often have their dye faded after a few years.
The earlier models were very chemically unstable and this made cyanine based discs unsuitable for archival use; they could fade and become unreadable in a few years.
...
Phthalocyanine dye CD-Rs are usually silver, gold or light green... Phthalocyanine is a natively stable dye (has no need for stabilizers) and CD-Rs based on this are often given a rated lifetime of hundreds of years.
...
Azo dye CD-Rs are dark blue in color... Azo dye is also chemically stable, and Azo CD-Rs are typically rated with a lifetime of decades.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
, it will die anyway when the system is powered off.
.
