Samsung 840 EVO: "SMART-healthy," works great, but too much LED activity

[BonzaiDuck]

This is still a mystery to me, and I thought maybe someone may know something I don't.

I've been upgrading my server. My server OS is WHS-2011 [based on Win 2008 R2].

I have installed two 4-port hardware SATA/RAID controllers in appropriate PCI-E slots (slots with more lanes than necessary), and the native Windows drivers are correctly installed: "Standard AHCI 1.0 ATA controller" is reported in Device Manager.

The system uses drive-pooling through StableBit, and I also installed StableBit scanner, which monitors the health of all disks in the system. Also, I have installed Samsung Magician, and it is fully functional except for inability to use RAPID_Mode, maybe because of the bandwidth limitations of the PCI-E 1.x slots used for the controllers. Everything else checks out: "Good," "Healthy" -- wonderful.

The only problem with the two Marvell-9230-based controllers: I either need to install a second LED light; install a drive light for every single drive; or live without the LED activity lights, since I have disabled the motherboard's onboard SATA controller.

Like other controller cards, the StarTech PEXSAT34RH units have a pair of LED pins for each SATA port, and a fifth pair labeled "ALL." So to avoid the trouble of installing seven more LEDs and wires in my case, I initially cabled the case's HDD LED to the "ALL" pins.

The flickering of the light suggests normal disk activity, but the light stays on . . . ALL . . the DAMN . . . . TIME!! There may not be much activity for the pooled HDDs -- one of which is on the same controller with the Sammy EVO boot-system SSD disk. Finally, I decided to remove the wires and connector from the "ALL" pins and locate the pins exclusive to the Samsung EVO SSD.

Behavior is the same!! The light is constantly on, even though it flickers to suggest normal disk activity. It has a default swap-file of 4GB. The monitoring software and Magician report nothing wrong.

But "IS THERE?" Is this "normal" for an SSD boot disk? This sort of activity-light behavior was not shown when the SSD was connected to the onboard nForce controller.

 

[dtgoodwin]

I'm using the same OS with Stablebit as well. I have an OCZ Vertex 2 SSD as my primary OS drive. My system is in a SuperMicro case with hot-swap drives that each show drive activity. The SATA port that the SSD is connected to is the on-board Intel, yet the behavior is the same as yours. The default state is the LED is lit. It actually blinks when there is activity (which is very often, but reads mostly). I put a different SSD (Patriot Pyro II) and it had the same behavior.

Mine has been in place for 1.5 years as the WHS system drive and it has only written about 3 TB of new data, while reading about 20 TB. At this rate, the drive will far outlive it's usefulness. I'm quite sure you have nothing to worry about.

 

[BonzaiDuck]

I'm using the same OS with Stablebit as well. I have an OCZ Vertex 2 SSD as my primary OS drive. My system is in a SuperMicro case with hot-swap drives that each show drive activity. The SATA port that the SSD is connected to is the on-board Intel, yet the behavior is the same as yours. The default state is the LED is lit. It actually blinks when there is activity (which is very often, but reads mostly). I put a different SSD (Patriot Pyro II) and it had the same behavior.

Mine has been in place for 1.5 years as the WHS system drive and it has only written about 3 TB of new data, while reading about 20 TB. At this rate, the drive will far outlive it's usefulness. I'm quite sure you have nothing to worry about.

Certainly, there would be no reason for you to mislead me about this, but it is encouraging to know. I say that especially because you're talking about an onboard Intel controller, while my two PCI_E controllers use the Marvell 9230 chip.

It is odd, though. You mention using a different SSD than mine -- an OCZ. I had previously installed my OS on a Mushkin 60GB SSD cabled to the onboard nForce controller, and the LED behaved as we usually expect it to. Of course, it also seemed "normal" when the OS was on an HDD in the interim, before putting it on the Sammy SSD.

On the other hand, now that I think of it, I have just tried an experiment to hook up the LED to the controller that is not hosting my boot-system Samsung SSD. And it dawns on me that I have the Mushkin connected to that second controller. Right now, that Mushkin is only being used for vol shadow copies and the Windows Swap or paging file.

So what you describe is one of the theories I held about this after discovering it yesterday -- you only know the drive is working hard when it gets dimmer.

I am still going to sort through the installed software on my WHS system. I have Magician as well as True Image installed, and I think they both do "monitoring." Add to that the Stablebit scanner.

For a while, I contemplated using a freeware software program to put an "LED" indicator in my system tray, but those things use their share of system RAM.

 

[BonzaiDuck]

Just an update -- even a casual query following dtgoodwin's response.

With new PCI-E SATA controllers, I simply wanted an LED showing "drive activity." This behavior of appearing "constantly on" is almost as bad as "no LED activity light." If dtgoodwin is correct, this is a common behavior for SSDs -- even connected to onboard controllers.

So should I expect to see the same thing, once I clone my workstation's HDD Win 7 installation to a Sammy 840 Pro?

Just wondering. It would seem that there should be some Device Manager feature of either the controller or the drive to "discipline" the activity light-LED. I noticed that you find such configuration features on an Intel onboard or "Pro" PCI-E NIC in the device manager tree, with explanations and guidance for each and every feature.

 

[GlacierFreeze]

Maybe the pins that control the LED light are mislabeled. I've seen that before. Incorrect power/hd led lighting even though I connected it correctly based on the mobo user manual. Had to figure it out myself that the diagram wasn't correct and had to swap some of the connections around to different pins. Wouldn't be surprised if that was the case.

 

[BonzaiDuck]

Maybe the pins that control the LED light are mislabeled. I've seen that before. Incorrect power/hd led lighting even though I connected it correctly based on the mobo user manual. Had to figure it out myself that the diagram wasn't correct and had to swap some of the connections around to different pins. Wouldn't be surprised if that was the case.

Several things.

I have three of these controllers, two in the same system working perfectly (otherwise).

Second, LEDs are only supposed to work at all -- in any respect -- if the polarity of the wiring is correct. They are either completely "off" or dysfunctional with the wiring reversed, or they will light up if the wiring is correct. If -- somehow -- newer hardware negates this common understanding of LEDs, I'd like to know it.

What I indeed discover is that plugging the wire to pins of an unused socket shows no LED activity. Plugging it to the SSD port's pins gives the same result as plugging it to the "ALL" pair.

Since this is a server and I'm more concerned about the actual pooled data HDDs, I may just connect the pins to the appropriate ports' LED pins for HDDs and forget about this other peculiar observation -- common to myself and at least dtgoodwin. But in such a situation, I'd be better off with an LED for each and every HDD in the system -- an argument in favor of a complete Hot-swap drive-tray approach to all those HDDs, or a lot of tedium to add two (or more) LEDs to my computer case with wiring for each HDD on the controllers.

Probably the best approach would be to put all the SSDs on one controller and all the HDDs on another -- except for a hot-swap HDD tray and the optical drive which have their own LEDs anyway. Then I can use the "ALL" pins for the controller exclusively fitted with HDDs.

I'm still wondering what to expect on my workstation when I clone my OS HDD to the Sammy 840. Somebody else might have a better idea.

 

[BonzaiDuck]

Again responding to dtgoodwin:

This is most strange. You have an onboard controller -- an Intel, for which my experience shows it to be dim or unlit more times than not; I have these Marvell PCI-E controllers, doing what yours does as you describe.

IT'S NOT AN SSD THING!!

I made sure to cable all my SSDs to a controller that is not connected to the LED. The disks on the other controller are HDDs.

The LED activity light just stays "on" most of the time, with activity shown in dropouts of the light intensity.

And somebody tell me if I'm wrong about the 1-way functionality of LEDs: correct polarity means they work; incorrect means they don't -- nary a flash of light.

 

[BonzaiDuck]

I'm using the same OS with Stablebit as well. .

CoveCube's (StableBit's) Tech-rep tells me that there might be a tweak to either their scanner software or Drive-Pool that could change this. I'm waiting for more detailed info. Of course- it was among the first things I thought of. "SMART querying" and other things, being misinterpreted as "disk activity."

 

[dtgoodwin]

Sorry I haven't responded back earlier. My symptoms more clearly described are this - best served by describing my system.
SuperMicro X9-SCM-F Intel Socket 1155 mobo
Intel I3-2100T processor
SuperMicro 8-port SAS controllers with Marvell 64xx controller and SATA breakout cables
SuperMicro 24-bay hot-swap server case

I am running an OCX Vertex 2 connected to port 0 of the onboard controller
I'm running ports 1-5 to conventional hard drives as well as using 6 ports of the 8 port SuperMicro controller

The SuperMicro backplane is able to detect drive activity itself - I don't know the SATA spec, but PATA had an activity pin you could tap into to light a LED for activity. I'm assuming SATA has the same, or with a chip on the backplane can accomplish the same thing.

Whatever hot-swap bay I put one of my two SSDs into (notable, both SandForce based), the LED has the opposite behavior of normal. It's on when idle, and off when there's activity. It doesn't matter whether it's going to the Intel controller or to the SuperMicro controller. My wife's computer has a Samsung 830, but I'm not in a position to test it to see if it's behavior is similar. It could very well be a SandForce bug. Of the platter drives I have, 10 are various WD's, mostly RED and GREEN series. I do have a Hitachi 80 GB laptop drive for the OS backup drive. All of them work as expected - the activity LED illuminating on drive access.

I've not worried too much about it. I use the built-in resource monitor and can see as a percentage, how busy the drive is, and quickly concluded that it's just reversed. I can live with it until this drive does. BTW, HOW has this Vertex 2 lasted as long as it has? I keep waiting for it to die, but I must be in the 1% of users that haven't had any problems with it.

 

[BonzaiDuck]

Sorry I haven't responded back earlier. My symptoms more clearly described are this - best served by describing my system.
SuperMicro X9-SCM-F Intel Socket 1155 mobo
Intel I3-2100T processor
SuperMicro 8-port SAS controllers with Marvell 64xx controller and SATA breakout cables
SuperMicro 24-bay hot-swap server case

I am running an OCX Vertex 2 connected to port 0 of the onboard controller
I'm running ports 1-5 to conventional hard drives as well as using 6 ports of the 8 port SuperMicro controller

The SuperMicro backplane is able to detect drive activity itself - I don't know the SATA spec, but PATA had an activity pin you could tap into to light a LED for activity. I'm assuming SATA has the same, or with a chip on the backplane can accomplish the same thing.

Whatever hot-swap bay I put one of my two SSDs into (notable, both SandForce based), the LED has the opposite behavior of normal. It's on when idle, and off when there's activity. It doesn't matter whether it's going to the Intel controller or to the SuperMicro controller. My wife's computer has a Samsung 830, but I'm not in a position to test it to see if it's behavior is similar. It could very well be a SandForce bug. Of the platter drives I have, 10 are various WD's, mostly RED and GREEN series. I do have a Hitachi 80 GB laptop drive for the OS backup drive. All of them work as expected - the activity LED illuminating on drive access.

I've not worried too much about it. I use the built-in resource monitor and can see as a percentage, how busy the drive is, and quickly concluded that it's just reversed. I can live with it until this drive does. BTW, HOW has this Vertex 2 lasted as long as it has? I keep waiting for it to die, but I must be in the 1% of users that haven't had any problems with it.

I've been troubleshooting another problem on my client workstation, and until recently didn't think it could be the ISRT SSD-caching configuration. But the Patriot SSD in the caching arrangement uses the Sandforce controller as I understand it. I am making preparations to exchange that configuration for a straight AHCI boot-system Samsung 840-Pro. I had heard here and there of glitches with Sandforce SSDs, but didn't think this sort of intermittent problem would be caused by it. I can't confirm either way.

This behavior of the HDD_LED "doesn't care" whether an SSD is cabled to a controller or the controller is used exclusively for platter disks. I have two CoveCube SW programs running on the server: StableBit Scanner and the version 2.xx of Drive-Pool. the LED behaved normally when disks were connected to the onboard nForce SATA controller, but I installed the PCI-E Marvell-based controllers so I could eliminate the nForce -- which didn't fully implement AHCI. Frankly, the speed these controllers provide through PCI-E version 1.x slots is still better than the onboard nForce -- now fully disabled in BIOS.

There is a "Throttle" option in the Scanner software, and I'm waiting to hear what can be done with that or with Drive Pool.

I'm also going to double the server memory, so it could be feasible to use an "LED-simulation" program and just disconnect the LED plug from one of the two controllers.

It's just interesting that we had similar OS configurations and discovered this peculiar drive-light phenomenon.