megaraid_sas: Optionally add SCSI devices for individual disks in a raidset

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.

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.

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)

------------

@@ -46,6 +46,12 @@
 #include <scsi/scsi_host.h>
 #include "megaraid_sas.h"
 
+static int export_disks = 0;
+module_param(export_disks, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(export_disks, "Export physical disks to the SCSI midlayer (DANGEROUS)"
+       " -1=protect 0=off 1=on");
+
+
 /*
  * poll_mode_io:1- schedule complete completion from q cmd
  */

@@ -905,8 +911,12 @@
         *        That will be fixed once LSI engineers have audited the
         *        firmware for possible issues.
         */
-       if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && sdev->type == TYPE_DISK)
-               return -ENXIO;
+       if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && sdev->type == TYPE_DISK)

{
+ if (export_disks < 0)
+ sdev->no_uld_attach = 1;
+ else if (export_disks == 0)
+ return -ENXIO;
+ }

/*
* The RAID firmware may require extended timeouts.
--------

MegaRAID SAS controllers are RAID controller, it is not a good idea to export the physical drives to the midlayer (also it is dangerous).

Regards,

Bo Yang

-----Original Message-----
From: Joe Malicki [mailto:[email protected]]
Sent: Tuesday, August 19, 2008 5:21 PM
To: DL-MegaRAID Linux; linux-poweredge; linux-scsi
Subject: megaraid_sas: Optionally add SCSI devices for individual disks in a raidset

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.

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.

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)

------------
--- linux-2.6.26.2-orig/drivers/scsi/megaraid/megaraid_sas.c 2008-08-06 12:19:01.000000000 -0400
+++ linux-2.6.26.2/drivers/scsi/megaraid/megaraid_sas.c 2008-08-19 +++ 17:12:02.000000000 -0400
@@ -46,6 +46,12 @@
#include <scsi/scsi_host.h>
#include "megaraid_sas.h"

+static int export_disks = 0;
+module_param(export_disks, int, S_IRUGO|S_IWUSR); +MODULE_PARM_DESC(export_disks, "Export physical disks to the SCSI midlayer (DANGEROUS)"
+ " -1=protect 0=off 1=on");
+
+
/*
* poll_mode_io:1- schedule complete completion from q cmd
*/
@@ -905,8 +911,12 @@
* That will be fixed once LSI engineers have audited the
* firmware for possible issues.
*/
- if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && sdev->type == TYPE_DISK)
- return -ENXIO;
+ if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && sdev->type ==
+ TYPE_DISK)
{
+ if (export_disks < 0)
+ sdev->no_uld_attach = 1;
+ else if (export_disks == 0)
+ return -ENXIO;
+ }

/*
* The RAID firmware may require extended timeouts.
--------

Hello,
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.

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.

megaraid_sas.export_disks=1 gives you the sdx devices

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. Greets,
Jochen

_______________________________________________
Linux-PowerEdge mailing list [email protected]
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq