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

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

[Joe Malicki]

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)

Signed-off-by: jmalicki@metacarta.com

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

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

[Yang, Bo]

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:jmalicki@metacarta.com]
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)

Signed-off-by: jmalicki@metacarta.com

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

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

[Jochen Radmacher]

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

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.

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

[-- Attachment #2: idlecheck.sh --]
[-- Type: application/x-sh, Size: 791 bytes --]

[-- Attachment #3: Type: text/plain, Size: 211 bytes --]

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