Somewhere in October last year I've assembled myself a nice little home server which was meant to be as silent as possible. The reason for this was that the server is basically located in my bedroom, and I didn't want the noise from all the fans and hard-disks to annoy me. In order to achieve this I've assembled a nice little machine with a Gigabyte motherboard with a dual-core Atom, Antec case, and two Western Digital Green series hard-disks. This all sounds quite nice and all, until I discovered a shocking truth about the above hard-disks - the hard way...
About a year or so later, I've noticed that my ssh logins to the home server take a substantial amount of time. I've also noticed that the servers seems to behave rather poorly when accessing data on it. After some time of negligence, I've finally tried to research what the problem might be and if anyone else on the Internet has had a same problem. Several very vague searches later, and I've pinpointed the issue to two possible problems. The first was that Western Digital has been switching over to the 4KB physical sector sizes instead of the traditional 512 bytes. This means that if you don't align the partitions properly, you might end-up with big performance penalties. Alas, this was not the problem that I faced myself.
The second problem mentioned was that WD Green series attempts to save power and reduce noise by parking the head of the hard-drive. This feature sounds all great and nice, and actually useful for my intention of keeping the server as silent as possible, except for one tiny problem... This parking happens every 8 seconds of idleness. On the other hand, the Linux kernel likes to access the hard-disk for something like every 30 seconds... In other words, the head gets constantly parked and loaded. Now comes the juicy part... According to Western Digital specs, the number of allowed head load/unload cycles during the lifetime of a hard-disk is 300.000. Lets get some simple maths into all this. The smallest whole number which contains whole parts of numbers of 30 and 8 (forgive my lack of knowledge of English mathematical expressions) is 120. We have 4 30-second cycles in 120 seconds. The number of load/unload cycles is times two, which brings it to 8 cycles per 2 minutes. This is 240 cycles per hour, 5760 per day, 172800 per month. Therefore the load/unload cycle limit is reached in less than two months. Frightening, isn't it? This means that after two months of usage, you have a very strong possibility of loosing the hard-disks and the data on them.
Of course, this calculation is highly pessimistic since it assumes that hard-disks are idle all the time (which is usually not the case) - although it could be even worse depending on the alignment of the 8s and 30s cycles. In case your hard-disks are constantly being read from and written to, the issue will not rear its ugly head. But, in my case, since it's a home server that sometimes remains idle for quite a lot of hours, it happened rather soon (although not as fast as the above two months).
Once I became aware of the problem, I've tried to figure out the number of load/unload cycles on my hard-disks. The command I used was:
$ smartctl -a /dev/sda | grep Load
I can't recall what the exact value was, but it was freaking huge, something in the range of 700.000. After finding out about it, I tried to find a way to disable this fancy IntelliPark feature (or should it be called DumbPark?) and ran into several articles mentioning the use of hdparm -S command. Upon obtaining new hard-disks (yes, I've bought WD Green series again, this time the 2TB versions) and migrating my home server to them, I've used the command to prolong the standby mode to something like 5 minutes or more. I've also setup a small cronjob to run the following script and append its output to a log file:
Notice that between 08:00 and 17:00 the number of load/unload cycles has increased only by a little. During this time I had some downloads running which kept the hard-disks busy. As soon as disk activity ceased, you can see the numbers jumping up quite rapidly. I was quite discontent with this, and after some searching I ran into utility issued by WD for increase the period for parking the head or disabling it altogether. The utility can be downloaded from:
Now, the moment you unpack it or read the description at the page you'll find out another idiotic truth... The utility is meant to be used under DOS. Yes, under freaking ancient DOS! And the instructions on the page don't even try to go into detail on how to actually boot a DOS system on a modern machine. The least they could've done was to create an ISO image that users could download, burn to CD, and boot from in order to start the utility. Instead they decided to leave it up to users to do this all by themselves. Luckily enough, there's enough how-to's and tutorials on achieving this. I felt a bit lazy, and after one more search ran into the following page:
Although I'm grateful to the author of the article above, I found the instructions within the comments section by Bruno Luna much faster and (at least for myself) simpler.
Just in case that this page goes to hell with a poof, I'll repaste his instructions here:
Thanks for the post, it was useful for me. But I used an alternative that I think it is easier. It requires just a usb stick.
1 - Download unetbootin:
'sudo apt-get install unetbootin' or direct from www.unetbootin.sourceforge.net
2 - Start the application. Select FreeDos as distribution in the main dialog. Your USB stick will probably be already selected in the lower dialog, if not, do it (remeber to format it first as FAT).
3 - The application will automatically download and install the odin version of freedos(just 1,4MB!). It will also make your usb bootable.
4 - Copy the wdidle3.exe to the usb stick.
5 - Reboot the system with the usb stick as first boot alternative. When asked select the live CD version of freeDOS.
6 - In the prompt type c:, so that you get to the root of the usb stick. Then type as usual wdidle3 /S255 and that's it!
I've had some issues while trying to boot FreeDOS on this particular machine until I selected the FreeDOS safe mode. Additionally, instead of setting the timer to a higher value, I've opted to use the /D flag and disable the feature altogether. After a reboot I've also had some trouble with Debian Lenny booting up and initialising very slowly, so I powered down the machine and started it again. The system came up quickly and after one more poweroff and repositioning of server into my room all was done.
I've let the system idle for an additional hour and checked the log file with recorded load/unload cycles. It had shown no change in numbers, which I wholeheartedly found to be a good thing. I'll try to let it run some more and post an update regarding the results I obtained.
As a final word I must say that I'm very disappointed by the way Western Digital seems to have behaved with regard to this issue. It is my strong opinion that they should have made the issue publicly known and informed users in a more proper way on how to solve the issue at hand. They also should've made complete instructions on how to tune the hard-disks. Let's not forget about the fact that they also decided to circumvent standard tools like hdparm/sdparm for changing these parameters, and instead opted for their own utility that runs only under an ancient operating system.
Ok, I've let the system run for a while with the Load/Unload cycle logger, and here are the results:
Copyright (C) 2012 Branko Majic. Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved. Code snippets found throughout the articles are licensed under GPLv3 or later.