The current method of having unRAID manage disk spindown has some "side effects".  When unRAID notices (and it does notice very quickly) that a disk has spun up (or down) for some unknown reason, it is quick to reverse the operation.  For example, if you run a smartctl on a sleeping disk, it will spin up long enough to run the smart report and then unRAID will shut it back down.  Try it on a Seagate disk (WD disks don't spin up for a smart report) and you will see smartctl pause while disk is spun up, but then afterwards if you refresh the tower gui, you'll see the disk is sleeping.  Same thing with hdparm -y (which spins down a disk).  Immediately unRAID will notice and spin the disk back up.

 

Only exception seems to be the "hdparm -S" command which sets a timeout for automatic drive spindown.  Drives will go to sleep after the interval and this goes unnoticed by unRAID.

 

I also believe that the HDIO_GET_IDENTITY issue with the Supermicro SAS card is causing the spinup / spindown cycling to occur.  I believe that every time you get this message in your log, the drive has been invisibly spun up (if it was sleeping) and then immediately put back to sleep by unRAID.  It is a little hard to catch unRAID in the act, but unsing myMain I have seen the disks spinup for unknown reasons, and then spindown immediately afterards.  I never saw this when running the Adaptec controller.

 

Not sure if drives have a "starter motor", but have to believe that spinning up and down drives over and over again is not healthy for the drives.

 

Joe has make a change to unmenu to eliminate the "hdparm -C" calls for the array disks.  This is a command that causes those HDIO log messages.  (If you have the SAS card, this is a "must have" update for you!)  

 

I am working on an update to myMain to eliminate them as well.  

 

But if you are seeing these in your logs, suggest you spin up your array while you are running commands that cause these log entries.  That should avoid the spindown/spinup cycles.

 

So Joe already "has" made this change in Unmenu?  If so.. when was this.  I recently updated.  Also.. I have noticed the behaviour you describe.  My system has 2 of the sas controllers.  Thanks for the post.

To avoid 99% of these HDIO_GET_IDENTITY errors, you have to update the unMENU and move the cache drive to a mobo SATA port, as the cache drive isn't controlled by de MD driver.

See this link for posts concerning the unmenu update.

 

Update occured in early August.

 

gfjardim is correct - move cache disk (and any other non-array disks) to non-SAS controller.  (Thanks gfjadim - you are the one that first posted the link between hdparm -C and the get identity errors)

This is not just Supermicro SAS controllers, but they appear to be the worst.  I have seen this on older ICH6 Intel chipsets too, with some drives.

 

It is not just the controllers that do it.... some drives, when spun down, if you make a SMART query, will spin up, return SMART and then spin right back down.  I ran into this testing many different drives for the unraid_info and other utilities.

Isn't Start_stop_count spin ups? (Smart) :-

 

4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       628

For some drives the attribute "193 Load_Cycle_Count" (LCC) is more telling. LCC is the count of load/unload cycles into head landing zone position.

 

The older WD drives would die completely once they reached some number (300,000 for WD AADS?). It didn't matter the age of drive at all. I think this mostly affected the laptop drives, but it might have affected normal desktop drives too, with some reports of issues on the WD EADS when they were new. In some situations the drive's LCC would increase by the thousands; at that rate the drive was set to die in well under 2 years, perhaps as few as 1 year.

 

I think the newer drives limits at 600,000 or higher and are tuned not to auto-park as frequently.

 

From Wikipedia:

The typical lifetime rating for laptop (2.5-in) hard drives is 300,000 to 600,000 load cycles.  Some laptop drives are programmed to unload the heads whenever there has not been any activity for about five seconds. Many Linux installations write to the file system a few times a minute in the background. As a result, there may be 100 or more load cycles per hour, and the load cycle rating may be exceeded in less than a year.