I was intrigued enough by your question to have a look at what could be done. Here’s a summary of what I found out.
- It seemed, at first, that the disks were exposed through normal block devices under /dev. I.e., there exists a /dev/sda through /dev/sde.
- I found a little utility called hddtemp ( https://savannah.nongnu.org/projects/hddtemp/ ) that accesses the SMART interface and prints out the temperature.
- A quick round of cross compiling later and I got it running on the FS.
- Unfortunately, this is what comes out of it:
# ./hddtemp /dev/sda
/dev/sda: DROBO DroboPro: S.M.A.R.T. not available
# ./hddtemp /dev/sdb
/dev/sdb: open: No such device or address
# ./hddtemp /dev/sdc
/dev/sdc: open: No such device or address
# ./hddtemp /dev/sdd
/dev/sdd: open: No such device or address
# ./hddtemp /dev/sde
/dev/sde: open: No such device or address
In other words: all the disks are hidden away behind a virtual /dev/sda block device.
This is pure speculation, but I think there probably is a proprietary interface to access that data, as it is usually the case with RAID controllers ( http://sourceforge.net/apps/trac/smartmontools/wiki ).
I’ll try to cross compile smartmontools, but I think it won’t help much. My guess is that DRI’s virtual SCSI device is not compatible with any of the ones supported by smartmontools.