Just checked my syslog and it's riddled with tons of yellow "minor issues" lines which all say that same thing:

 

Nov 4 12:53:42 Tower ata_id[826]: HDIO_GET_IDENTITY failed for '/dev/block/8:32'

 

There's literally 00s of these lines, any idea what this is?

 

Thanks

Just checked my syslog and it's riddled with tons of yellow "minor issues" lines which all say that same thing:

 

Nov 4 12:53:42 Tower ata_id[826]: HDIO_GET_IDENTITY failed for '/dev/block/8:32'

 

There's literally 00s of these lines, any idea what this is?

 

Thanks

It indicates your SATA card driver does not support the HDIO_GET_IDENTITY io control command.

 

It also probably indicates you are running a program that uses "hdparm" (which is issuing that command to learn the capabilities of the disk)

 

You can ignore the lines... they do no harm, and you cannot do anything to eliminate them short of getting an updated driver in some future release of unRAID where it has been implemented.

 

If you are running unMENU (which uses hdparm as part of the commands used to determine the status of your array, upgrade to the newest version which minimizes the use of the hdparm command.)

 

Joe L.

I am seeing an oddity with this.  I am using the temp control script which issues the hdparm command to determine if the hard drive is sleeping.  Of my 10 drives, 5 of them issue this error.  3 of the non error drives are on the motherboard (only 3 on the motherboard right now.)  The other 7 drives are spread across 2 AOC-SASLP-MV8 cards.  5 of those drives are generating the error and 2 are not.  The 5 generating the error are ears and eads drives having a drive identity field looking like:

 

WDC_WD20EARS-00_WD-Wxxxxxxxxxx or WDC_WD20EADS-00_WD-Wxxxxxxxxxx

 

The two on the supermicro cards not generating the error are ears drives with a drive indetity field looking like:

 

WDC_WD20EARS-00MVWB0_WD-Wxxxxxxxxxxx

 

So it would seem that the drives are a factor in whether or not this error occurs as well.