How to prevent external USB hard disk from unloading its heads?

I have a 2.5" hard disk (Seagate 1TB) connected to a raspberry pi4 via a USB-SATA bridge. The bridge chip is an ASM1153e which supports UASP. The issue is that the heads keep unloading. This was determined by looking at the SMART data every few minutes.

This is what I've tried so far. None of them helps. If anything, it keeps the disk perpetually loading and unloading the heads. Any points would be much appreciated

1. Using camcontrol to disable sleep, standby & apm
camcontrol idle da0 -t 0
camcontrol standby da0 -t 0
camcontrol apm da0 -l 254

2. Ran a cron job every minute which basically does this:
dd if=/dev/da0 of=/dev/null bs=1M count=9 iflag=direct
 
Several years ago, I solved a similar issue by writing AND flushing small amounts of data every 4 s to a disk, which did excessive load cycling on a macOS computer. And here the crucial point was, to flush the write cache, otherwise the writes wouldn't hit the disk frequently enough for having the desired effect.

Now your apporach is similar, however, I am almost sure that you need to do it more frequently. And the underlying disk access of dd may be subject of caching as well. In this case, 9 Mbyte would be initially read from the disk, and then the disk won’t be touched by this almost never again - however I am not sure about this.

For my macOS problem, I wrote a daemon for doing the frequent write-flushes. I am almost sure, that this would compile and run on FreeBSD as well — https://github.com/cyclaero/lccguard. Perhaps, you want to give it a try.
 
First, try to download the detailed manual for your exact drive model from Seagate. Seagate is pretty good about publishing the detailed SATA/SCSI protocol documents for their devices. But only "pretty" good; parameters such as power saving modes may not be fully documented, in particular not for consumer devices. The reason behind that is that there is an expectation that consumers will not go down to the protocol level and modify device settings. The situation is different for enterprise devices (which are sold to Amazon/EMC/Google/HP/IBM/Microsoft/Oracle), where documentation about many more details is shared with the volume purchasers of the disks. By the way, little anecdote: For enterprise disks, about 99% of all disks are sold to ~10 customers, which are the companies on the list above and similar ones.

If you can get the detailed description of the power mode settings from the manuals, you can try to tune whether the disk goes to "sleep" (that includes unloading the heads). But it's quite possible that this is not even tunable, for two reasons: first, this disk may be intended for the consumer market, where there is no expectation that users will want to tune the behavior.

Second, it's very likely that Seagate has already adjusted the various drive parameters (head unload, spindle spindown, electronics sleep mode) both for optimal power usage and optimal disk lifetime. Modern disks wear out: Spindle bearings slowly lose lubricant, the spindle lubricant changes chemical composition (due to oxydation and partial distillation as they age), the lubricant that covers the platters also ages, and it interacts with the head (often leaving a thin film of lubricant on the head as the disk ages). There is a reason that disk manufacturers today specify a total annual IO throughput (typically 550 TB/year), and if one exceeds that, it voids the warranty. If you change the unload or spindown parameters, you might actually reduce the lifetime of your disk, and that may be why Seagate doesn't want you to do that (and doesn't document how), or makes it flat out impossible.

For an individual purchaser of a single disk, it may be impossible to get documentation about these technical details; on the other hand, for customers that buy hundreds of thousands of disks, working directly with Seagate engineering is common. If you insist on turning head unload off, you might want to try first finding documentation about it that's available to individuals, and then purchase a disk that can actually do it.
 
looks like a wd green clone :)
these love to park heads also.
had used a wd green 24/7 a few years and park count was ~900k iirc
 
I had the same problem with an external WD hard disk a few years ago - it was the firmware in the case, not the drive causing the issue. Solution was to rehouse the disk in a generic case.
 
I have a batch of 4 2TB WD Greens, used in my server for many years in a ZFS RAIDz array. Yes, they do have a tendancy to unload heads and spin down, something very problematic in a RAIDz array. But I did my research before going for this much cheaper option. There is/was a firmware update on the WD site that turned off the "green" features. They are still in use now, but in a different box as a backup for the more important stuff on my now bigger server array :)
 
my opinion on such drives: just let it die and get it replaced as often as it fails during the warranty period.
If vendors (still!) put such crap on the market, they should be making as much loss with it as possible.
 
my opinion on such drives: just let it die and get it replaced as often as it fails during the warranty period.
If vendors (still!) put such crap on the market, they should be making as much loss with it as possible.
While I in general agree with your approach: This is an external 2.5" USB hard drive. I doubt that they are expected/designed to be used for anything other than "occasional access".
 
my opinion on such drives: just let it die and get it replaced as often as it fails during the warranty period.
If vendors (still!) put such crap on the market, they should be making as much loss with it as possible.
Hehehehe, in fact your are right. I do understand the reaction of jbodenmann, but it's all business. If you read the product site, you don't have the impression it is meant for occasional access.
 
If you are looking for a light solution that does an fsync(2) after a write check out my cstream utility:

cstream -o /mnt/myusb/tmp -i - -n 4k -O F

I think the port is out of date, you need the newest version that has -O F, which means do fsync(2) on the output file at program end:

Doing that often enough should keep the head flying.
 
Back
Top