megaraid_sas: Optionally add SCSI devices for individual disks in a raidset
jr at dioscuri.de
Sun Aug 24 09:51:22 CDT 2008
I am running a similar patch for some time now, and haven't had any
problems so far. (I posted the patch a while ago in linux-scsi, but
nobody cared.) The only difference is, that I hardcoded the creation of
the sgx devices and additionally made them read only. (sdev->writeable=1;)
This is what I have tested so far (kernel 2.6.24):
"smartctl --device=sat --all /dev/sgx" (5.38) This works for all
harddisks. The controller logs an "Unexpected sense" for the smart
response from the hardrive, but this doesn't do any harm.
The smart daemon does not work corretly in this version
hdparm (v8.6) mostly works, but setting the suspend timeouts doesn't
show any effekt. Manually supending (hdparm -y) works.
My main intention was suspending the harddrives automatically if the are
not used, so I wrote this little script. (idlecheck, see attachment) The
wakeup is done automatically by the controller and takes about 6seconds
per disk in the raid array.
Joe Malicki wrote:
> This is very dangerous, and you shouldn't use it/apply it unless you're feeling adventurous.
> This lets one, optionally, add /dev/sg* devices, and optionally also /dev/sd* devices, for
> disks in a RAIDset. It is modeled after similar functionality in the aacraid driver.
Just a little sidenote: If I remember my experiments correctly, the
device nodes for the individual disks get created in front of the nodes
for the array, so you need to change the fstab entries if you use this flag.
> I've been successfully using this to upgrade individual disk firmwares behind a Dell PERC
> RAID controller with sgdskfl from scsirastools - AFTER the RAID array has been stopped
> with other tools.
> Use the kernel option "megaraid_sas.export_disks=-1" to get /dev/sg* devices. Unless a
> specific option has been given, the patch doesn't modify behavior.
megaraid_sas.export_disks=1 gives you the sdx devices
> Note that the driver currently says (and has said for some time):
> * FIXME: Currently we don't export them to the midlayer at all.
> * That will be fixed once LSI engineers have audited the
> * firmware for possible issues.
> So using this is certainly high risk and one should be careful.
> (only signing off so others may feel free to use it, not encouraging this
> to go anywhere unless LSI feels it's safe)
The only thing LSI needs to change in the firmware is the handling of
external smart requests, so it doesn't create a warning in the log.
One more idea (If it is possible): It would be nice, if the driver could
detect, when a drive is used in an array and not create an sdx node for it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 791 bytes
Desc: not available
Url : http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20080824/2a1e948a/attachment.bin
More information about the Linux-PowerEdge