Patch: allow devices to restrict start on add

Patch: allow devices to restrict start on add

[Eddie Williams]

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


When a SCSI disk is added and it returns a NOT READY the SD driver is 
automatically sending a START_UNIT command to spin the device up.  While this 
may be the desired behavior for many if not most devices not all devices 
either want or need this.  The attached patch provides a mechanism via the 
device_list that allows a device to be defined to disable the automatic start 
being issued on an add.

The patch also modifies the device_list for several devices that would prefer 
to not have the start command issued. 

Eddie Williams

[-- Attachment #2: nostart.diff --]
[-- Type: text/x-diff, Size: 3044 bytes --]

diff -Nru linux-2.5.69/drivers/scsi.notready/scsi.h linux-2.5.69/drivers/scsi/scsi.h
--- linux-2.5.69/drivers/scsi.notready/scsi.h	Thu May  8 15:20:18 2003
+++ linux-2.5.69/drivers/scsi/scsi.h	Thu May  8 15:26:44 2003
@@ -612,6 +612,7 @@
 	unsigned remap:1;	/* support remapping  */
 //	unsigned sync:1;	/* Sync transfer state, managed by host */
 //	unsigned wide:1;	/* WIDE transfer state, managed by host */
+	unsigned no_start_on_add:1;	/* do not issue start on add */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */
 
diff -Nru linux-2.5.69/drivers/scsi.notready/scsi_scan.c linux-2.5.69/drivers/scsi/scsi_scan.c
--- linux-2.5.69/drivers/scsi.notready/scsi_scan.c	Thu May  8 15:20:18 2003
+++ linux-2.5.69/drivers/scsi/scsi_scan.c	Thu May  8 15:26:44 2003
@@ -52,6 +52,7 @@
 #define BLIST_LARGELUN		0x200	/* LUNs past 7 on a SCSI-2 device */
 #define BLIST_INQUIRY_36	0x400	/* override additional length field */
 #define BLIST_INQUIRY_58	0x800	/* ... for broken inquiry responses */
+#define BLIST_NOSTARTONADD	0x1000	/* do not do automatic start on add */
 
 /*
  * scsi_static_device_list: deprecated list of devices that require
@@ -152,7 +153,7 @@
 	{"EMULEX", "MD21/S2     ESDI", NULL, BLIST_SINGLELUN},
 	{"CANON", "IPUBJD", NULL, BLIST_SPARSELUN},
 	{"nCipher", "Fastness Crypto", NULL, BLIST_FORCELUN},
-	{"DEC", "HSG80", NULL, BLIST_FORCELUN},
+	{"DEC", "HSG80", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
 	{"COMPAQ", "LOGICAL VOLUME", NULL, BLIST_FORCELUN},
 	{"COMPAQ", "CR3500", NULL, BLIST_FORCELUN},
 	{"NEC", "PD-1 ODX654P", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
@@ -180,7 +181,10 @@
 	{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
 	{"ADAPTEC", "AACRAID", NULL, BLIST_FORCELUN},
 	{"ADAPTEC", "Adaptec 5400S", NULL, BLIST_FORCELUN},
-	{"COMPAQ", "MSA1000", NULL, BLIST_FORCELUN},
+	{"COMPAQ", "MSA1000", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"COMPAQ", "MSA1000 VOLUME", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"COMPAQ", "HSV110", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"HP", "HSV100", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
 	{"HP", "C1557A", NULL, BLIST_FORCELUN},
 	{"IBM", "AuSaV1S2", NULL, BLIST_FORCELUN},
 	{"FSC", "CentricStor", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
@@ -804,6 +808,13 @@
 	 */
 	if ((*bflags & BLIST_BORKEN) == 0)
 		sdev->borken = 0;
+
+	/*
+	 * Some devices may not want to have a start command automatically
+	 * issued when a device is added.
+	 */
+	if (*bflags & BLIST_NOSTARTONADD)
+		sdev->no_start_on_add = 1;
 
 	/*
 	 * If we need to allow I/O to only one of the luns attached to
diff -Nru linux-2.5.69/drivers/scsi.notready/sd.c linux-2.5.69/drivers/scsi/sd.c
--- linux-2.5.69/drivers/scsi.notready/sd.c	Thu May  8 15:20:18 2003
+++ linux-2.5.69/drivers/scsi/sd.c	Thu May  8 15:26:44 2003
@@ -852,7 +852,10 @@
 			break;
 		}
 					
-					
+		/* The device does not want the automatic start to be issued. */
+		if (sdkp->device->no_start_on_add) {
+			break;
+		}
 
 		/*
 		 * If manual intervention is required, or this is an

Re: Patch: allow devices to restrict start on add

[Patrick Mansfield]

Eddie -

On Thu, May 22, 2003 at 11:40:59AM -0400, Eddie Williams wrote:
> When a SCSI disk is added and it returns a NOT READY the SD driver is 
> automatically sending a START_UNIT command to spin the device up.  While this 
> may be the desired behavior for many if not most devices not all devices 
> either want or need this.  The attached patch provides a mechanism via the 

Can you elaborate on "want or need this"? Do they get errors?

Is this a clusters issue?

Also you should patch against scsi-misc-2.5, or a recent bk, since hch
moved all of the devinfo code into scsi_devinfo.c

-- Patrick Mansfield

Re: Patch: allow devices to restrict start on add

[Eddie Williams]

On Thursday 22 May 2003 02:05 pm, Patrick Mansfield wrote:
> Eddie -
>
> On Thu, May 22, 2003 at 11:40:59AM -0400, Eddie Williams wrote:
> > When a SCSI disk is added and it returns a NOT READY the SD driver is
> > automatically sending a START_UNIT command to spin the device up.  While
> > this may be the desired behavior for many if not most devices not all
> > devices either want or need this.  The attached patch provides a
> > mechanism via the
>
> Can you elaborate on "want or need this"? Do they get errors?

The "problem" is that some devices use a start unit to activate a LUN on a 
passive path.  So if the device has 2 paths then as SCSI is scanning down one 
path start units are issued to activate the LUNs on that path.  When SCSI 
scans the next path it issues the starts to activate the LUNs down that path.  
The causes "thrashing."  Perhaps you can imagine what the affect may be if 
there are multiple boxes booting.  This switching of the LUNs from one path 
to another causes IO's to have to be rerouted and thus great disruption to 
the IO activity.

At times I have seen other discussions on this list where there have been 
complaints about automatically issuing START_UNIT.  Perhaps this feature 
would be able to satisfy those concerns as well?  I have not gone through the 
archives to see the particular discussions through.

>
> Is this a clusters issue?

The particular problem I am seeing is a multi-path SAN issue.  Any box 
connected to a SAN that reboots causes start units to get issued down each 
path of a device.


>
> Also you should patch against scsi-misc-2.5, or a recent bk, since hch
> moved all of the devinfo code into scsi_devinfo.c

Yes.  I had taken a snapshot of the kernel a couple of weeks ago but it took a 
while for me to test it out but did not go back and remerge.  I will have 
that out tomorrow.

Eddie

Re: Patch: allow devices to restrict start on add

[Eddie Williams]

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

> On Thursday 22 May 2003 04:10 pm, Eddie Williams wrote:
> > On Thursday 22 May 2003 02:05 pm, Patrick Mansfield wrote:

> > Also you should patch against scsi-misc-2.5, or a recent bk, since hch
> > moved all of the devinfo code into scsi_devinfo.c
>
> Yes.  I had taken a snapshot of the kernel a couple of weeks ago but it
> took a while for me to test it out but did not go back and remerge.  I will
> have that out tomorrow.

I updated to bk16.

Eddie

[-- Attachment #2: noadd.bk16.diff --]
[-- Type: text/x-diff, Size: 3489 bytes --]

diff -Nru linux-2.5.69/drivers/scsi.orig/scsi.h linux-2.5.69/drivers/scsi/scsi.h
--- linux-2.5.69/drivers/scsi.orig/scsi.h	Fri May 23 10:38:43 2003
+++ linux-2.5.69/drivers/scsi/scsi.h	Fri May 23 11:01:50 2003
@@ -389,6 +389,7 @@
 	unsigned remap:1;	/* support remapping  */
 //	unsigned sync:1;	/* Sync transfer state, managed by host */
 //	unsigned wide:1;	/* WIDE transfer state, managed by host */
+	unsigned no_start_on_add:1;	/* do not issue start on add */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */
 
diff -Nru linux-2.5.69/drivers/scsi.orig/scsi_devinfo.c linux-2.5.69/drivers/scsi/scsi_devinfo.c
--- linux-2.5.69/drivers/scsi.orig/scsi_devinfo.c	Fri May 23 10:29:20 2003
+++ linux-2.5.69/drivers/scsi/scsi_devinfo.c	Fri May 23 11:01:50 2003
@@ -131,7 +131,7 @@
 	{"EMULEX", "MD21/S2     ESDI", NULL, BLIST_SINGLELUN},
 	{"CANON", "IPUBJD", NULL, BLIST_SPARSELUN},
 	{"nCipher", "Fastness Crypto", NULL, BLIST_FORCELUN},
-	{"DEC", "HSG80", NULL, BLIST_FORCELUN},
+	{"DEC", "HSG80", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
 	{"COMPAQ", "LOGICAL VOLUME", NULL, BLIST_FORCELUN},
 	{"COMPAQ", "CR3500", NULL, BLIST_FORCELUN},
 	{"NEC", "PD-1 ODX654P", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
@@ -159,7 +159,10 @@
 	{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
 	{"ADAPTEC", "AACRAID", NULL, BLIST_FORCELUN},
 	{"ADAPTEC", "Adaptec 5400S", NULL, BLIST_FORCELUN},
-	{"COMPAQ", "MSA1000", NULL, BLIST_FORCELUN},
+	{"COMPAQ", "MSA1000", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"COMPAQ", "MSA1000 VOLUME", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"COMPAQ", "HSV110", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
+	{"HP", "HSV100", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
 	{"HP", "C1557A", NULL, BLIST_FORCELUN},
 	{"IBM", "AuSaV1S2", NULL, BLIST_FORCELUN},
 	{"FSC", "CentricStor", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
diff -Nru linux-2.5.69/drivers/scsi.orig/scsi_devinfo.h linux-2.5.69/drivers/scsi/scsi_devinfo.h
--- linux-2.5.69/drivers/scsi.orig/scsi_devinfo.h	Fri May 23 10:32:57 2003
+++ linux-2.5.69/drivers/scsi/scsi_devinfo.h	Fri May 23 11:01:50 2003
@@ -14,3 +14,4 @@
 #define BLIST_LARGELUN		0x200	/* LUNs past 7 on a SCSI-2 device */
 #define BLIST_INQUIRY_36	0x400	/* override additional length field */
 #define BLIST_INQUIRY_58	0x800	/* ... for broken inquiry responses */
+#define BLIST_NOSTARTONADD      0x1000  /* do not do automatic start on add */
diff -Nru linux-2.5.69/drivers/scsi.orig/scsi_scan.c linux-2.5.69/drivers/scsi/scsi_scan.c
--- linux-2.5.69/drivers/scsi.orig/scsi_scan.c	Fri May 23 10:37:35 2003
+++ linux-2.5.69/drivers/scsi/scsi_scan.c	Fri May 23 11:01:50 2003
@@ -641,6 +641,13 @@
 		sdev->borken = 0;
 
 	/*
+	 * Some devices may not want to have a start command automatically
+	 * issued when a device is added.
+	 */
+	if (*bflags & BLIST_NOSTARTONADD)
+		sdev->no_start_on_add = 1;
+
+	/*
 	 * If we need to allow I/O to only one of the luns attached to
 	 * this target id at a time set single_lun, and allocate or modify
 	 * sdev_target.
diff -Nru linux-2.5.69/drivers/scsi.orig/sd.c linux-2.5.69/drivers/scsi/sd.c
--- linux-2.5.69/drivers/scsi.orig/sd.c	Fri May 23 10:39:39 2003
+++ linux-2.5.69/drivers/scsi/sd.c	Fri May 23 11:01:50 2003
@@ -855,7 +855,12 @@
 			break;
 		}
 					
-					
+		/*
+		 * The device does not want the automatic start to be issued.
+		 */
+		if (sdkp->device->no_start_on_add) {
+			break;
+		}
 
 		/*
 		 * If manual intervention is required, or this is an

Re: Patch: allow devices to restrict start on add

[Luben Tuikov]

Eddie Williams wrote:
> When a SCSI disk is added and it returns a NOT READY the SD driver is 
> automatically sending a START_UNIT command to spin the device up.  While this 
> may be the desired behavior for many if not most devices not all devices 
> either want or need this.

Eddie, 

Could you please report what the ASC is when NOT READY is
returned in this particular situation? (ASCQ should be 0)

Maybe the ASC can be used for fine graining (and thus generalizing a rule),
rather than just adding another entry to the black list.

Thanks,
-- 
Luben

Re: Patch: allow devices to restrict start on add

[Eddie Williams]

On Thursday 22 May 2003 02:30 pm, Luben Tuikov wrote:
> Eddie Williams wrote:
> > When a SCSI disk is added and it returns a NOT READY the SD driver is
> > automatically sending a START_UNIT command to spin the device up.  While
> > this may be the desired behavior for many if not most devices not all
> > devices either want or need this.
>
> Eddie,
>
> Could you please report what the ASC is when NOT READY is
> returned in this particular situation? (ASCQ should be 0)

Sense_Key=2 Not Ready
ASC: 0x04, ASQ: 0x02 Logical Unit Not Ready, Initializing Command Required

>
> Maybe the ASC can be used for fine graining (and thus generalizing a rule),
> rather than just adding another entry to the black list.

I had already mentioned to the vendor that returning 3 would avoid the start 
unit but this hardware has been doing this for a long time so with the 
concern of breaking something else my suggestion was not accepted.


Eddie

Re: Patch: allow devices to restrict start on add

[Luben Tuikov]

Eddie Williams wrote:
> 
> Sense_Key=2 Not Ready
> ASC: 0x04, ASQ: 0x02 Logical Unit Not Ready, Initializing Command Required

Thanks Eddie.

Has anyone seen this condition for locally attached (same host)
(block) devices?  Or is it only generated by the multipathing soft/hardware.

What I'd like to know is if this condition plus another (which I'm about
to investigate) will give a pretty consistent rule for multipathed
devices.

Thanks,
-- 
Luben

Re: Patch: allow devices to restrict start on add

[Douglas Gilbert]

Luben Tuikov wrote:
> Eddie Williams wrote:
> 
>>
>> Sense_Key=2 Not Ready
>> ASC: 0x04, ASQ: 0x02 Logical Unit Not Ready, Initializing Command 
>> Required
> 
> 
> Thanks Eddie.
> 
> Has anyone seen this condition for locally attached (same host)
> (block) devices?  Or is it only generated by the multipathing 
> soft/hardware.

Luben,
That ASC/ASQ sequence is precisely what I see after
I spin down a Fujitsu MAM3184 (ditto for a Seagate
ST318451). The disk below is directly attached with a
single initiator. The 'sg_start 0 /dev/sg3' command spins
down the second Fujitsu disk:

# lsscsi -g
[0:0:1:0]    disk    FUJITSU  MAM3184MP        0106  /dev/sda  /dev/sg0
[1:0:3:0]    disk    FUJITSU  MAM3184MP        0105  /dev/sdb  /dev/sg3
[2:0:0:0]    cd      ATAPI    CD-RW 48X16      A.RZ  -         /dev/sg1
[3:0:0:0]    cd      CREATIVE CD5233E          1.00  -         /dev/sg2
#
# sg_dd if=/dev/sg3 of=. bs=512 count=1
1+0 records in
1+0 records out
#
# sg_start 0 /dev/sg3
#
# sg_dd if=/dev/sg3 of=. bs=512 count=1
reading: scsi status: Check Condition
Current, Sense key: Not Ready
[valid=0] Info fld=0x0, Additional sense: Logical unit not ready, 
initializing cmd. required
Raw sense data (in hex):
   70 00 02 00 00 00 00 28 00 00 00 00 04 02 00 00 00 00 03 28 00 01 05 03
   00 00 00 00 00 00 00 00
plus...: Driver_status=0x08 (DRIVER_SENSE,SUGGEST_OK)
sg_read failed, skip=0
Some error occurred,  remaining block count=1
0+0 records in
0+0 records out

So ASC,ASQ=0x4,0x2 is the normal response for recent disks
when they are sent commands (typically other than INQUIRY)
when they are spun down.

> What I'd like to know is if this condition plus another (which I'm about
> to investigate) will give a pretty consistent rule for multipathed
> devices.

Doug Gilbert

Re: Patch: allow devices to restrict start on add

[Luben Tuikov]

Douglas Gilbert wrote:
>
[...]
> 

Thanks Doug.  Very detailed and helpful.

> So ASC,ASQ=0x4,0x2 is the normal response for recent disks
> when they are sent commands (typically other than INQUIRY)
> when they are spun down.

Yes, this is indeed the case...

-- 
Luben