Question Odd-sounding SAS drive

Aug 30, 2020
2
0
10
0
Hi Folks,

I have an intermittently noisy SAS drive, only at idle, and I cannot for the life of me work out what the cause is. My system is an HP Z420, LSI 9212 SAS controller and a Seagate SS33000650SS SAS drive (there are more SSD and SATA drives, but the Seagate is the noisy one). It came from a server recycling company, along with 4 others, all of which are fine, but in another system (Microserver Gen 8 with P222 RAID controller, although in all fairness they don't have time to be idle). The drive works fine, has no SMART issues, and is everything I need it to be, except silent at idle.

The noise is like a head seek, but it happens 5 or 6 times a second, and is there over 90% of the time. and each occurrence of the sound is almost identical. What I mean there is that it is not doing a random seek (assuming if it is a seek), it's doing (almost) the same seek each time. There are many reports of the head parking sound that happens during power management idle_b state, but I've turned off all power management, and I still get it. it is independent of all other hardware, as it happens even when just powered up with no data connection. all I have to do is access the drive and the sound stops. If I set it to do a sequential read, it stays silent the whole time, but as soon as the read finishes, it starts the noise again.

I have bought and used literally hundreds of SAS drives in the past (possibly thousands), but I have never put one in a workstation before, so it may be the this is normal for a SAS drive. anyone have any ideas if this is normal, or ideas about how to make it go away?

(sort-of edit: after i finished the above paragraph, it fell silent, and I went out for 2 hours. an hour after getting home., it's not made a sound).

TIA

DM
 
Aug 30, 2020
2
0
10
0
I agree with you :) Drive is 9 years old currently, and has completed a grand total of 10 background scans. They are set for daily, so all of those have happened since I bought it. Unfortunately, I can't turn it off - sdparm tells me that the attribute is not changeable:

root@HP-Z420-Workstation:/usr/bin# sdparm /dev/sde -p bc -v
/dev/sde: SEAGATE ST33000650SS XRR6
Background control (SBC) [0x1c,0x1] mode page [PS=1]:
S_L_FULL 0 [cha: n, def: 0, sav: 0]
LOWIR 0 [cha: n, def: 0, sav: 0]
EN_BMS 1 [cha: n, def: 1, sav: 1]
EN_PS 0 [cha: y, def: 0, sav: 0]
BMS_I 72 [cha: y, def: 72, sav: 72]
BPS_TL 24 [cha: y, def: 24, sav: 24]
MIN_IDLE 500 [cha: y, def:500, sav:500]
MAX_SUSP 0 [cha: y, def: 0, sav: 0]


and I see no other mechanism to disable it. It's clearly never run this before, and the number of scans reported is just 11 now and it is 9 years old. Either it has never been idle, or it has been disabled in some other way. I'm going to consider this solved, as I know what it is, still happy to hear suggestions for turning it off.

Thanks.
 
Nov 30, 2021
1
0
10
0
I've encountered the same issue with the same exact HDD model: ST33000650SS. I know, I'm necro-posting here, but this might be useful to someone else out there.

I've bought these HDDs from eBay few years ago, for my home server, and ever since they've been producing this annoying repeating noise at idling due to the constantly running BMS. I understand that those drives were meant to work in a server room, not in a leaving room, but setting the BMS flag to read-only mode is just an evil thing to do on the part of Seagate's engineers.

Also worth mentioning that same exact HDD produced under Dell's brand (aka Dell Enterprise Plus) allows setting the BMS flag off. So it's a matter of firmware. Hence, first thing I've attempted to do, is to upgrade the firmware, hoping that Seagate just made a misstake and this issue would've be corrected in the newer firmware.

The latest firmware I was able to find on Segates site for ST33000650SS was 0005 (All my Segate drives had 0003 and Dell's had RE12/RS12). However, same issue was present in the new firmware as well - the BMS flag was set to read-only mode (cha: n).

Second thing I've attempted to do, is to flash Dell's firmware to Segate's drives. That involved some serious Hex editing to circumvent Susdupie (Dell's firmware flashing utility) to accept Segate's drives as Dell own drives. While I've succeeded at that, it lead to some other unforeseen issues and I had to re-flash the HDDs back to their stock firmware.

The third thing I've tried, is more of an exploit, rather than a real solution:

I've set MIN_IDLE flag to 65534:
sdparm --set=MIN_IDLE=65534 PD? --save

Note: it's a short integer (or integer - if you're an old school VB/C programmer ;)), if you set it to 65535 it will be equal -1, anything beyond that would set it to 0. I didn't see much difference between setting it to 65534 and to -1.

This flag tells the hard drive how much time (in ms) it has to wait (when idling) before it starts running the background media scan.

I've also set BPS_TL=0. This tells the HDD how long the background scan is permitted to take after disk powers on (in hours), and EN_PS=0 - disable init (pre-scan) background media scan at the next disk power-on.

Now, all I had to do, is to run some kind of an app that would access the HDD every 30 seconds (or less) to prevent it from idling and thus preventing the MIN_IDLE timer from expiring. In my case, I'm using HDD Setinel to display the temperatures in Windows system tray, so all I had to do, is to adjust the frequency at which HDD Setinel reads the Smart info. I've set it to 30 seconds and the noise was gone forever.

I also thought about using smartctl and Windows task scheduler, to run a script that would read some basic smart info of the drives, thus preventing them from going idle, and would also know to stop if the drives were spun down, to prevent them from sniping up again. But I didn't have time to check that idea properly. I guess if you don't have HDD Setinel, you could try using smartctl (smartctl -i -n standby /dev/sd?) instead, or any other similar utility.

I know it's not an elegant solution, but it's better than nothing. Hope it helps someone else who might stumble upon this problem.
 
Last edited:

ASK THE COMMUNITY

TRENDING THREADS