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)
property disks as disk
method blink_disk (disk.gethealth)
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
should i not bother?