SC846 Drive Carrier LEDs off

[melloa]

Guys,

All my drive carrier LEDs on my SC846 went off after I inserted a SSD with an adapter on one of the bays, connected to the HBAs used by the FreeNAS VM. All drives continue working, but all LEDs are dead. I haven't find anything to point to the cause of this problem. If someone has any ideas how to get the LEDs working again I'd appreciate.

The seller description of my backplane says it takes SSD, so maybe the adapter caused the problem: Backplane: BPN-SAS-846A 24-port 4U SAS 6Gbps direct-attached backplane, support up to 24x 3.5-inch SAS2/SATA3 HDD/SSD

The server has 4x LSI 9210-8i HBA JBOD, by the way, to allow flexibility on passing through to several VMs on the esxi server. Two are dedicated to a FreeNAS VM, but all LEDs, including the ones not connected to those specific HBAs are also off, so I'm thinking I've fried something on backplane that controls those LEDs ....

Any ideas will be appreciated.

 

[Ericloewe]

I vaguely remember this. Might have been a backplane limitation when using SAS and SATA disks?

 

[melloa]

I vaguely remember this. Might have been a backplane limitation when using SAS and SATA disks?

Not sure, Eric. All HDDs are SATA WD Red 4TiB. I was planning to play with adding cache and stuff to the pool to see what performance improvement I'd get. At the end I've continued the test with that same SSD connected to a SATA port on my MB and using a vdisk. I did get some improvement; from 110 KB/s to 148 KB/s transfer rate from my linux to the smb export using Nautilus.

Code:

root@mellonas:~ # zpool status
  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0 days 00:00:17 with 0 errors on Sun Sep  2 03:45:17 2018
config:

	NAME		STATE	 READ WRITE CKSUM
	freenas-boot  ONLINE	   0	 0	 0
	  mirror-0  ONLINE	   0	 0	 0
		da0p2   ONLINE	   0	 0	 0
		da1p2   ONLINE	   0	 0	 0

errors: No known data errors

  pool: raid
 state: ONLINE
  scan: scrub repaired 0 in 0 days 03:42:22 with 0 errors on Sun Jul 29 03:42:24 2018
config:

	NAME											STATE	 READ WRITE CKSUM
	raid											ONLINE	   0	 0	 0
	  raidz3-0									  ONLINE	   0	 0	 0
		gptid/9cc74ca1-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/9e400a05-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/9fa4f774-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a10b9194-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a28b763f-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a410f7f2-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a58a8f80-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a65a93c0-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a797b80d-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/a9106428-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
		gptid/2f87603e-4803-11e8-87c9-000c295dadfe  ONLINE	   0	 0	 0
		gptid/abf1f88f-45dd-11e8-9237-000c295dadfe  ONLINE	   0	 0	 0
	cache
	  gptid/569a1c12-afbb-11e8-868c-000c295dadfe	ONLINE	   0	 0	 0

errors: No known data errors

I can't pass through the SATA ports as they are used by esxi.

One thing that I've noticed, even before the cache added, was that the copy hangs for few seconds at 99% before completes. It that a delay caused by the data been committed?

[]'s,
Al

 

[Ericloewe]

from 110 KB/s to 148 KB/s

You sure about those units? Those figures are really low...

One thing that I've noticed, even before the cache added, was that the copy hangs for few seconds at 99% before completes. It that a delay caused by the data been committed?

It wouldn't be on FreeNAS' end. Assuming no very weird bottlenecks, the transfer should reach steady-state performance after a few seconds, as far as the pool is concerned. I've seen Windows do something like that, but it's always been short enough to attribute to a mixture of anticipation by the user and some files towards the end being smaller and lowering transfer rates.

As for the backplane, does the problem persist after removing the drive that seemingly caused this?

 

[melloa]

You sure about those units? Those figures are really low...

Man ... I'm going crazy. Sorry.

As for the backplane, does the problem persist after removing the drive that seemingly caused this?

Yeap, it does. All is working, so I don't care at this point. Will replace when $ fall from the trees ... :D

 

[kdragon75]

Just a heads up on this...

Backplane: BPN-SAS-846A 24-port 4U SAS 6Gbps direct-attached backplane, support up to 24x 3.5-inch SAS2/SATA3 HDD/SSD

https://www.supermicro.com/manuals/other/BPN-SAS-846A.pdf
https://ami.com/ami_downloads/AMI_Backplane_Controller_MG9072_Data_Sheet.pdf
That's SAS1 and that means 3Gb per lane. Also much more limited SSD support. I'm guessing you got it for $150usd give or take. You should expect to double that for a BPN-SAS2-846A. That's why I'm looking into something like a NetApp DS4246/DS2246. That with a Dell H200E cross flashed.

 

[cobrakiller58]

My understanding of the A/TQ series backplanes is that they act just like the SAS cables of the same era and work with SAS2/3 as they do not manage any data. I could be mistaken however....

 

[Ericloewe]

The only fancy thing they do is light up for activity and presumably as a SCSI Enclosure Services (SES) device.

 

[melloa]

Okay ... I'm back here.

As of today I haven't found the cause for my back plane failure, but as a word of warning it happened when I connected a SSD to one of the bays, so unless you are 100% sure that won't burn your back plane, don't do it.

That caused all LEDs on the board and 8 of the bays to go dead.

After three days of full back-up, I've replaced the board and all it back to 100% working condition.

$170 short, but happy that all is back to normal.

I'll, of course, reset that board and connect to a test board ... someday ...