A few weeks ago I ordered myself a new eco friendly home server. The machine will be acting as my content server: running samba, sabnzbd, nginx and mysql. Most of the time it will be idling, so my goal was to build a server with energy saving hardware. The old server already had a 1TB Western Digital Green Cavair drive in it which I bought in 2010. So I placed an order for the following parts:
- MSI H61M-P22 motherboard
- Intel Pentium G620
- Transcend JetRam JM1333KLN-2G
- be quiet! Pure Power L7 300W
Within a few days I received the whole shipment, and a few hours later my server was up and running again
. After installing and configuring Debian Squeeze I measured the power usage: 22 ~ 25 watt idle, not bad! I didn’t tweak anything at all, so I started my journey. Spinning down the disk after a period of idling was my next goal. For Linux users, hdparm is the tool which gets the job done. On Debian or Ubuntu all you need to do is:
# apt-get install hdparm
To configure your drive you have to know its name. One way to figure that out is
# fdisk -l
Output on my system:
root@vegeta:~# fdisk -l Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0c8b0915 Device Boot Start End Blocks Id System Disk /dev/sdb: 16.0 GB, 16022241280 bytes 255 heads, 63 sectors/track, 1947 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000b2232 Device Boot Start End Blocks Id System /dev/sdb1 * 1 1863 14957568 83 Linux /dev/sdb2 1863 1948 686081 5 Extended /dev/sdb5 1863 1948 686080 82 Linux swap / Solaris
The /dev/sdb device is the USB key running the OS, while /dev/sda is my WD Green Caviar drive.
To set the spindown time all you have to do is:
# hdparm -S 5 /dev/sda /dev/sda: setting standby to 5 (25 seconds)
Of course you should change the time out if you want. However, after waiting 25 seconds I did a status check:
# hdparm -C /dev/sda /dev/sda: drive state is: active/idle
What the?
It obviously didn’t work! After trying some more time outs I concluded it didn’t really work. Googling for my drive and hdparm I quickly found a lot of other people which ran in the same problem. Furthermore I discovered that Linux and the old Western Digital Green Caviar drives don’t play well with each other. To summarize: the drive puts heads into parking position after 8 seconds idle time! This causes a very high Load_Cycle_Count. To check this, you have to install the smartctl utility:
# apt-get install smartmontools
Then, check the S.M.A.R.T. data for you drive:
# smartctl -a /dev/sda smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net ... Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 105 088 021 Pre-fail Always - 7741 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 453 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 9144 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 399 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 40 193 Load_Cycle_Count 0x0032 187 187 000 Old_age Always - 41449 194 Temperature_Celsius 0x0022 117 100 000 Old_age Always - 30
When issuing this command for a couple of minutes, I saw the number growing rapidly: every 3 minutes a new hit. Not good!
Fix the drive for Linux usage
Western Digital published a advisory about this problem. Basically we as Linux users are left in the dark. They provide a tool to reset of reconfigure the timeout, but it only runs on MS-DOS…
The good news is that the utility is present on the Ultimate Boot CD. Burn the ISO on a disc (or make a bootable USB key) and remove the timeout with:
wdidle3.exe /D
After that you’re drive will pay attention to the settings provided by hdparm, and the Load_Cycle_Count won’t be growing that rapidly. The count on my server grows by 2 counts per day, instead of ~ 200!
And when the drives is standby my server consumes 18 ~ 20 watt!
If you ever need to do this again, there is a Linux app available nowadays:
http://idle3-tools.sourceforge.net/
I’ve had my home server for too long before noticing this problem, so I now have a load cycle count somewhere north of 45000!
Thanks for linux alternative! And my server was online too for a few years before noticing, resulting in a load cycle count of 41449 at the time I was writing this post
.
Hey together, I noticed this problem today with a WD30EZRX.
First I wanted to share some more experience to this blog post and ask you if it is the same for you. Western Digital addresses the problem as following: “Some utilities, operating systems, and applications, such as some implementations of Linux, for example, are not optimized for low power storage devices and can cause our drives to wake up at a higher rate than normal.” This sounds a little easy. With other words: Linux is the bad player. And also what I see this is to easy and nonsense. If I activate Standby by hand with “hdparm -y /dev/sdc”, my hard drive is in standby until I wake it up by my own hands. It is a secondary drive and so nothing writes to it if I don’t do that manually. When I don’t do this, I have a Load_Cycle_Count every few seconds. Here is definitely something wrong with Western Digital and not Linux. Can you reproduce this?
I’ve disabled the function in my drive so I cannot reproduce it any more. But my drive refused to enter standby modus at all…. It’s indeed too easy to blame Linux for this. WD is the real problem I guess