Requesting thoughts on disks vs backplanes and talking to them

Hardware
1

first time rockstor user frequent listener

here’s the thing - i’ve had a specific problem that i’m travelling down may rabbit holes to solve
got too involved with my specific problem until i backed away from it a moment

installed rockstor on some “vintage” hardware -worked a treat - installed an HP hotswap SAS backplane (vintage) to replace the sff 8087 to x4 sas drive cable - leds don’t work in the drive cage

all well and good - lsi hba card supports sgpio but no i2c socket on it. hp backplane only has i2c socket - there’s the disconnect.

then i realised that rockstor needs control of the disks (jbod) - usually it’s the raid controller that’s monitoring the health of the drives and doing the signalling to the status leds about pre-fail/failed/rebuild et all using the IBPI blinking pattern.

question: how does rockstor do this

in pass through mode the controller card doesn’t add anything to the commands going out to the disks/backplane. how do we then signal disk activity(not so important) and disk status/health (very important) if the disks are in a back plane?

is rockstor using sgpio to signal this sort of stuff?

maybe a common object that can interpret the current rockstor “known” health charateristics of the raid and the btrfs setup and translate to IBPI or invent our own for the two led and three led backplanes

i’m currently working on getting the i2c stuff working with this particular hp backplane via a usb–>i2c card (best part is i can plug it into my client pc - run the i2c cable to the backplane in the server and play around with the i2c byte stream without affecting the server operation

but big picture

  • some sort of device class in python (ignore my non python nomenclature)

class disk
property: health
method: get_health

class: backplane
property disks[] as disk
method blink_disk (disk.gethealth)

class mobo_backplane
inherits backplane

class sat-l_backplane
inherits backplane

class sgpio_backplane
inherits backplane

class i2c_backplane
inherits backplane

etc etc
override methods as necessary

i’m working on the i2c commands for hp - but they really don’t want to help s i’m just going to go through a sequential set of i2c commands once i find their addresses and see what sort of led behaviour eventuates

thoughts anyone?
should i not bother?

1 Like
2

further to this i’m pretty sure the hp backplane i’ve got would only have to have an 8 bit register per device on the i2c bus given that the hp can flash 2 leds blue/amber green/amber - jsut a matter of locating the addresses of the leds and playing with a a state machine to see which is which

3

actually - that’s exactly what it needs at rockstor end - and communicate through i2c sgpio or sat-l encapsulation

4

Hey Greg,
have you found a solution to control the LEDs on the backplane?

I bought a HP backplane aswell and I use it with an SFF 8484 to SATA cable with the internal SATA ports on my mainboard. This works totally fine but I would be nice to have a the status LEDs working.

Is it possible to control the LEDs with an USB to i2c adaptor like you described?

Thanks in advance :wink:

5

sort of - i used an hp backplane - but those hp backplanes are usually controlled by the hp server mobo (with a dedicated i2c cable) and the hp server software does the rest

i wrote some vala code to interrogate the usb - i2c and yes - managed to get status and activity lights to do stuff - but it would take some changes to rockstor itself to get such a configuration working - and given the number of devices out there i’m guessing it would be a maintenance nightmare for the devs to implement - a nice to have but probably not feasible