Welcome! Log In Create A New Profile


External USB drives and Load Cycle Counts

Posted by restamp 
External USB drives and Load Cycle Counts
April 06, 2013 01:12AM
I have recently been investigating the suitability of small 2.5" pocket disk drives in a 24/7 application as the main drive on an Arm (Pogoplug, Dockstar, etc.) server. These drives are nice to use because they are self-contained, take little power, and require only one connection to the outside world -- the USB cable. I have one such server which I set up in January using an old Western Digital 160GB pocket drive I had lying around. It has worked flawlessly, but the drive itself seemed to make a slightly worrysome reset sound on a regular basis. With the aid of the smartmontool smartctl, I noticed the drive was racking up a huge number of Load_Cycle_Count events. Further investigation (via Google) revealed that this drive, like many pocket drives, is designed to park the heads by default if the drive has not been accessed for 5 seconds. This may make sense in a typical applcation where the drive is subject to being physically knocked around, but Unix on a quiescent box has background tasks which can still result in disk accesses several times a minute. In a server application, the net result is that the heads are constantly being parked and unparked. The drive keeps tabs on how many times this occurs and the smartctl command can be used to view this and other data. In approximately 3 months of run time, my little WD drive had parked and unparked its heads over a quarter million times, and most drives are lifetime speced at 300-600k head parks. Thus, these drives could easily exceed their lifetime design in the respect in well within a year of normal use.

One solution is to forego the use of these pocket drives in this application. A conventional 3.5" drive in an external enclosure will typically not have this sort of programming. Another option is to turn off this head-parking function in the drive. The most recent smartctl program has a facility to do this, but unfortunately, the version packaged with Debian Squeeze and Wheezy predates the addition of this code. It is fairly straightforward to download the latest smartmontools tarball from sourceforge and compile your own copy, though.

My question: Is anyone else here using 2.5" portable drives as their storage device on their Plug servers? If so, what sort experience have you had with these drives? Have you taken any steps to deal with this problem? Finally, it's late here, but if people are interested I can give you more specific details at a later point in time as to how I've worked around this problem. But, I'm mainly curious whether others have seen any problems with these small drives in the application.

Re: External USB drives and Load Cycle Counts
April 06, 2013 02:17AM

I use a 2.5" HDD as the boot drive for my kernel building Goflex Net. I was aware of this problem with the "green" drives, so I used the manufacturer's tool to set the sleep period to "never". Mine is a Hitachi drive, and I used the tool from their website to do that on Win 7. As long as you use the OEM tool to set the sleep period either to never or a really long period, it will never park. This is a common problem when people use a "green" drive for 24/7 operation, and it is also the main concern for people with a Raid NAS (i.e. they don't want the drive to go to sleep at all). However, for my NAS (Goflex Home and Pogo E02), I boot with a USB thumb, and use the HDD as the storage drive, so I set the sleep period to 20 minutes to let it sleep during the time nobody accesses it.

I also found that for certain drives, using hdparm to set the sleep cycle will work fine, too.

Forum Wiki
bodhi's corner
Re: External USB drives and Load Cycle Counts
April 06, 2013 03:20AM
It is a special WesternDigital "feature"! :-)
Their 2.5" and Green 3.5" drives tend to park their heads after a few seconds of idle time (I think the default on my 2.5" scorpio blue drives was 8 seconds).
It's only logical that this behaviour eventually will kill the mechanics in the drive. But, this way they can propagate energy savings, while having you going out to buy a new drive sooner than later.

There is a tool that can disable this firmware based idle timer that can't be influenced by tools like hdparm. I can't remember the exact name ATM, but with a little googling, you should find it in no time.

Here's a useful link, which itself should include links to the needed WD tool.

Edited 1 time(s). Last edit at 04/06/2013 02:48PM by ingmar_k.
Re: External USB drives and Load Cycle Counts
April 06, 2013 02:48PM
- Most of Seagate drives work with hdparm
- Try hdparm first, if it does not work, try sdparm.
Re: External USB drives and Load Cycle Counts
April 06, 2013 02:51PM
This particular problem should be limited to WD only. I am not aware of another HDD manufacturer with such a aggressive firmware based idle timer.
As bodhi said, drives from other manufacturers should be compatible with the standard tools concerning power management.
Re: External USB drives and Load Cycle Counts
April 06, 2013 08:09PM
I've observed this auto-parking "feature" in my WDs and also in my Toshiba 2.5" external drives. The Seagates I've encountered to date don't seem to have gone this route, or perhaps just don't keep tabs on and/or report the number of head parkings. But I have one Seagate 2.5" drive that has been running for years on a Dockstar and is still going strong.

A problem with these USB drives is that there are literally hundreds of USB bridges out there, and each requires a slightly different approach to get/set this information from the drive. I haven't used hdparm in a while, but the new facility in smartctl allows you to pull in some glue code (via the '-d' option) to do this and it works fairly well, provided someone has already figured out the intricacies of your particular controller bridge.

The other thing I noticed, at least about the Toshibas, is that although you can tweak the drive's Advanced Power Management functions, it seem to reset itself to the default when the drive is power cycled, so it may perhaps be necessary to put the APM set command in rc.local so that it is re-applied on each boot. This was problematic for me, though, because until I built my own version of smartctl I didn't have a way of applying these tweaks from the Plug box itself.

For now, I'm using an old IDE drive an external USB case. This drive doesn't even support APM, but is working quite well. If I need to employ one of the Toshiba drives, I'll port the new smartctl and use it to turn off the auto-park feature from within rc.local, but sometimes older and simpler is better.
Re: External USB drives and Load Cycle Counts
April 07, 2013 12:15AM
I used a Seagate ST2000DL004/Samsung HD204UI 2T hdd with a Transcend JetFlash 2G usb.

The hdd spins down after idling around 15min.

Here is the stats:

(%8)(00:10)(punk)~> sudo smartctl -a /dev/sdb | grep 'Load_Cycle\|Power_On_Hours'                                                                                         
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       853
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1161

Re: External USB drives and Load Cycle Counts
April 07, 2013 01:43AM
Very similar here, syong, except I'm running a SheevaPlug with an SD-card root:
Device Model:     ST2000DL003-9VT166
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       12998
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       23
189 High_Fly_Writes         0x003a   086   086   000    Old_age   Always       -       14
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       11
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       2393

This disk has been a real work-horse. It was put into service in August, 2011, and has nothing critical on it -- mostly just old TV shows I've recorded and either wanted to keep or never gotten around to watching. I'd hate to lose some of them, but they're not quite worth the effort of putting a backup drive in service for. The drive is still reliable, but it is getting a tad louder than it used to be when it spins up.

I can't quite explain the Load_Cycle_Count on this one: In 1.66 years that would average out to 4 per day, but I'm sure the disk spins up many more times than this on a typical day. Also, the Power_On_Hours look a tad low if it's measuring power-to-the-electronics, and fairly high if it's measuring hours the platters are turning.

Also, can anyone give me a layman's explanation for what these "High_Fly_Writes" are? (Inquiring minds and all that...)
Re: External USB drives and Load Cycle Counts
April 07, 2013 08:14AM

The Load_Cycle_Count on yours looks really low comparing with Power_On_Hours. Have you changed idle time on it? I did not do anything on mine. Here is more details:
(%8)(07:55)(punk)~> sudo smartctl -a /dev/sdb | grep 'Device Model\|Power_On\|Power_Cycle\|High_Fly\|Power-Off\|Load_Cycle'                                               
Device Model:     ST2000DL004 HD204UI
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       854
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       33
192 Power-Off_Retract_Count 0x0022   252   252   000    Old_age   Always       -       0
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1166

Comparing to last snapshot, Power_On_Hours looks right as it should be sleeping when I slept.:) (To make sure, I put gkrellweather data in \tmp). My hdd does not have High_Fly_Writes. From wikipedia, seems it is a protection mechanism:


HDD producers implement a Fly Height Monitor that attempts to provide additional protections for write operations by detecting when a recording head is flying outside its normal operating range. If an unsafe fly height condition is encountered, the write process is stopped, and the information is rewritten or reallocated to a safe region of the hard drive. This attribute indicates the count of these errors detected over the lifetime of the drive.
This feature is implemented in most modern Seagate drives[1] and some of Western Digital’s drives, beginning with the WD Enterprise WDE18300 and WDE9180 Ultra2 SCSI hard drives, and will be included on all future WD Enterprise products.

Re: External USB drives and Load Cycle Counts
April 08, 2013 12:02AM
Just a reporting that I succeed in changing idle time on my hdd by:

(%8)(23:51)(punk)~/ws> sudo hdparm -S 255 /dev/sdb

 setting standby to 255 (21 minutes + 15 seconds)
 HDIO_DRIVE_CMD(setidle) failed: Invalid argument

There is a error which I guess is from trying to spin down the drive. However, the idle time is changed accordingly tested by my actually timing it.

Re: External USB drives and Load Cycle Counts
April 08, 2013 09:57PM
Thanks for the info syong. I played with hdparm years ago, but the latest version of smartctl seems to have everything I need to control the disk. I'm really more concerned about the automatic head parking than the spin downs. Usually, my system is busy enough that the main disks never spin down due to not being accessed recently.

Regarding High_Fly_Writes, yes, I am familiar with this boiler-plate description, but what does it actually mean? Is the head flying too close to the surface? Too far away? Or, am I not even thinking of the correct thing? Why does this occur? An aberration on the platter? And what is the significance? A head crash? A write that has errors? It's not that I can do anything about it -- I know I can't -- but I'd sort of like to know what's actually going on to provoke this condition. But, thanks for the cite never-the-less.
Re: External USB drives and Load Cycle Counts
April 08, 2013 10:59PM

You are welcome. Thank you for the information about smartctl.

I guess the out of safe zoom flying of the head is mainly caused by the wearing of the rotor in the hdd?

All these are new to me, please pardon me if my understanding seems too naive.


Your Email:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.