Fw: SCSI device not spinning up on rw

Fw: SCSI device not spinning up on rw

[Andrew Morton]

Begin forwarded message:

Date: Sat, 03 Jun 2006 21:47:48 +0200
From: Ruben Faelens <parasietje@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: SCSI device not spinning up on rw


I have a SCSI disk, which I want to spin down when the system is not in
use. I do this by using sdparm, scsi-spin or sg-utils. These tools all
spin down the SCSI drive by using an IOCTL.

Problem is that the kernel doesn't spin the drive back up. When a
process requests data from the disk (a simple ls), the kernel responds
with an I/O error. After some of these errors, reiserfs marks the drive
read-only.

This bug is also described here:
http://bugzilla.kernel.org/show_bug.cgi?id=6627

This bug was solved by scsi-idle (http://lost-habit.com/scsi.html) in
2.4 kernels, but the patch hasn't been ported to 2.6. It's also a dirty
hack, by someone who knows little of the internals of the SCSI system.

I read the LKML-archives, and they turned up some old posts in 09-2005
about this subject, where somebody says implementing this in SCSI could
get messy.

However, it seems to me that all it takes is a call to sd_spinup_disk()
in sd.c. When I add this in sd_init_command, the kernel crashes when
confronted with a SCSI disk. Then again, I'm no kernel hacker, this is
the first time I even read the source...

Could someone more experienced than me look into this? IMHO this should
be doable, because the spinup-on-read/write has been implemented in SATA
and IDE I/O subsystems. Then again, I read SATA and IDE disks handle
this for themselves.

So if someone would enlighten me, that would be great!

As a side note: maybe it's my disk that's having these problems? It's an
old SCSI disk in a HP 712/80 from 1994. Manual spinup does work however...


Ruben Faelens
BELGIUM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: SCSI device not spinning up on rw

[Douglas Gilbert]

Andrew Morton wrote:
> 
> Begin forwarded message:
> 
> Date: Sat, 03 Jun 2006 21:47:48 +0200
> From: Ruben Faelens <parasietje@gmail.com>
> To: LKML <linux-kernel@vger.kernel.org>
> Subject: SCSI device not spinning up on rw
> 
> 
> I have a SCSI disk, which I want to spin down when the system is not in
> use. I do this by using sdparm, scsi-spin or sg-utils. These tools all
> spin down the SCSI drive by using an IOCTL.
> 
> Problem is that the kernel doesn't spin the drive back up. When a
> process requests data from the disk (a simple ls), the kernel responds
> with an I/O error. After some of these errors, reiserfs marks the drive
> read-only.
> 
> This bug is also described here:
> http://bugzilla.kernel.org/show_bug.cgi?id=6627
> 
> This bug was solved by scsi-idle (http://lost-habit.com/scsi.html) in
> 2.4 kernels, but the patch hasn't been ported to 2.6. It's also a dirty
> hack, by someone who knows little of the internals of the SCSI system.
> 
> I read the LKML-archives, and they turned up some old posts in 09-2005
> about this subject, where somebody says implementing this in SCSI could
> get messy.
> 
> However, it seems to me that all it takes is a call to sd_spinup_disk()
> in sd.c. When I add this in sd_init_command, the kernel crashes when
> confronted with a SCSI disk. Then again, I'm no kernel hacker, this is
> the first time I even read the source...
> 
> Could someone more experienced than me look into this? IMHO this should
> be doable, because the spinup-on-read/write has been implemented in SATA
> and IDE I/O subsystems. Then again, I read SATA and IDE disks handle
> this for themselves.
> 
> So if someone would enlighten me, that would be great!
> 
> As a side note: maybe it's my disk that's having these problems? It's an
> old SCSI disk in a HP 712/80 from 1994. Manual spinup does work however...

Ruben,
IMO the sd driver should spin up drives if need be.
Perhaps the sd driver could have a parameter to
control this. Note that spinning up can take up to
30 seconds so some timeouts might go off upstream.

However this has been happening silently for a long
time in the ATA disk world. A timeout (e.g. using
'hdparm -S <n>') spins down the disk and the next
data transfer command to that disk spins it back
up again with an attendant delay for read commands.

The SCSI power management model uses the START STOP UNIT
SCSI command. Apart from the fact that the sd driver
actually has to do something when a "not ready,
initializing command required" error occurs, the
same thing would be happening as far as the higher layers
are concerned (i.e. reads are delayed).

To see how silly the current situation is consider a SATA
disk behind a SAT layer **. If I use the "front door" and
stop the disk with a START STOP UNIT SCSI command then
SAT will put the SATA disk into standby mode. Active intervention
is needed by the sd driver to spin it up but sd doesn't play.
Now if I use the "back door" and send a STANDBY ATA command
via the ATA PASS THROUGH SCSI command then the SATA disk
goes into standby mode (spins down). However the first
data transfer command will spin up the disk without the
sd driver doing anything.

I have a page summarizing power management in SCSI and
ATA: http://sg.torque.net/sg/power.html


** I'm using the sat-r08.pdf draft as a reference here,
   not what libata's SATL does today.

Doug Gilbert

Re: Fw: SCSI device not spinning up on rw

[Brian King]

Douglas Gilbert wrote:
>> I have a SCSI disk, which I want to spin down when the system is not in
>> use. I do this by using sdparm, scsi-spin or sg-utils. These tools all
>> spin down the SCSI drive by using an IOCTL.
>>
>> Problem is that the kernel doesn't spin the drive back up. When a
>> process requests data from the disk (a simple ls), the kernel responds
>> with an I/O error. After some of these errors, reiserfs marks the drive
>> read-only.

Setting sdev->allow_restart in struct scsi_device will cause sense
key/code/qual of 02/04/02 (not ready, initialization command required)
to wake up the scsi error handler and will force scsi core to issue
a start unit command to the disk. I added this a while back to handle
ipr raid arrays which need a start unit command each time the adapter
gets reset. It would be easy enough for sd to use this, either
all the time, or only when directed to, or we could add a sysfs attribute
to the disk to enable/disable this behavior.

Brian

Re: Fw: SCSI device not spinning up on rw

[Brian King]

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

Brian King wrote:
> Douglas Gilbert wrote:
>>> I have a SCSI disk, which I want to spin down when the system is not in
>>> use. I do this by using sdparm, scsi-spin or sg-utils. These tools all
>>> spin down the SCSI drive by using an IOCTL.
>>>
>>> Problem is that the kernel doesn't spin the drive back up. When a
>>> process requests data from the disk (a simple ls), the kernel responds
>>> with an I/O error. After some of these errors, reiserfs marks the drive
>>> read-only.
> 
> Setting sdev->allow_restart in struct scsi_device will cause sense
> key/code/qual of 02/04/02 (not ready, initialization command required)
> to wake up the scsi error handler and will force scsi core to issue
> a start unit command to the disk. I added this a while back to handle
> ipr raid arrays which need a start unit command each time the adapter
> gets reset. It would be easy enough for sd to use this, either
> all the time, or only when directed to, or we could add a sysfs attribute
> to the disk to enable/disable this behavior.

Please try the attached patch. It adds a sysfs device attribute "allow_restart".
If you set it to 1, then scsi core will issue a start unit when it sees 02/04/02
sense data. The attribute is in the same place as the FUA and cache_type
attributes (eg. /sys/block/sdc/device/scsi_disk:1:1:9:0/allow_restart). 


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sd_allow_restart_sysfs_attr.patch --]
[-- Type: text/x-patch; name="sd_allow_restart_sysfs_attr.patch", Size: 1621 bytes --]



Signed-off-by: Brian King <brking@us.ibm.com>
---

 linux-2.6-bjking1/drivers/scsi/sd.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+)

diff -puN drivers/scsi/sd.c~sd_allow_restart_sysfs_attr drivers/scsi/sd.c
--- linux-2.6/drivers/scsi/sd.c~sd_allow_restart_sysfs_attr	2006-06-05 12:33:06.000000000 -0500
+++ linux-2.6-bjking1/drivers/scsi/sd.c	2006-06-05 12:34:22.000000000 -0500
@@ -208,6 +208,23 @@ static ssize_t sd_store_cache_type(struc
 	return count;
 }
 
+static ssize_t sd_store_allow_restart(struct class_device *cdev, const char *buf,
+				      size_t count)
+{
+	struct scsi_disk *sdkp = to_scsi_disk(cdev);
+	struct scsi_device *sdp = sdkp->device;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	if (sdp->type != TYPE_DISK)
+		return -EINVAL;
+
+	sdp->allow_restart = simple_strtoul(buf, NULL, 10);
+
+	return count;
+}
+
 static ssize_t sd_show_cache_type(struct class_device *cdev, char *buf)
 {
 	struct scsi_disk *sdkp = to_scsi_disk(cdev);
@@ -223,10 +240,19 @@ static ssize_t sd_show_fua(struct class_
 	return snprintf(buf, 20, "%u\n", sdkp->DPOFUA);
 }
 
+static ssize_t sd_show_allow_restart(struct class_device *cdev, char *buf)
+{
+	struct scsi_disk *sdkp = to_scsi_disk(cdev);
+
+	return snprintf(buf, 40, "%d\n", sdkp->device->allow_restart);
+}
+
 static struct class_device_attribute sd_disk_attrs[] = {
 	__ATTR(cache_type, S_IRUGO|S_IWUSR, sd_show_cache_type,
 	       sd_store_cache_type),
 	__ATTR(FUA, S_IRUGO, sd_show_fua, NULL),
+	__ATTR(allow_restart, S_IRUGO|S_IWUSR, sd_show_allow_restart,
+	       sd_store_allow_restart),
 	__ATTR_NULL,
 };
 
_

Re: Fw: SCSI device not spinning up on rw

[Olaf Hering]

 On Mon, Jun 05, Brian King wrote:

> Brian King wrote:
> > Douglas Gilbert wrote:
> >>> I have a SCSI disk, which I want to spin down when the system is not in
> >>> use. I do this by using sdparm, scsi-spin or sg-utils. These tools all
> >>> spin down the SCSI drive by using an IOCTL.
> >>>
> >>> Problem is that the kernel doesn't spin the drive back up. When a
> >>> process requests data from the disk (a simple ls), the kernel responds
> >>> with an I/O error. After some of these errors, reiserfs marks the drive
> >>> read-only.
> > 
> > Setting sdev->allow_restart in struct scsi_device will cause sense
> > key/code/qual of 02/04/02 (not ready, initialization command required)
> > to wake up the scsi error handler and will force scsi core to issue
> > a start unit command to the disk. I added this a while back to handle
> > ipr raid arrays which need a start unit command each time the adapter
> > gets reset. It would be easy enough for sd to use this, either
> > all the time, or only when directed to, or we could add a sysfs attribute
> > to the disk to enable/disable this behavior.
> 
> Please try the attached patch. It adds a sysfs device attribute "allow_restart".
> If you set it to 1, then scsi core will issue a start unit when it sees 02/04/02
> sense data. The attribute is in the same place as the FUA and cache_type
> attributes (eg. /sys/block/sdc/device/scsi_disk:1:1:9:0/allow_restart). 

Is it safe to have this attribute be 1 per default, and let the user
disable it for problematic drives? The IO errors bother me alot...

Re: Fw: SCSI device not spinning up on rw

[Stefan Richter]

Olaf Hering wrote:
>  On Mon, Jun 05, Brian King wrote:
>>Brian King wrote:
...
>>>Setting sdev->allow_restart in struct scsi_device will cause sense
>>>key/code/qual of 02/04/02 (not ready, initialization command required)
>>>to wake up the scsi error handler and will force scsi core to issue
>>>a start unit command to the disk. I added this a while back to handle
>>>ipr raid arrays which need a start unit command each time the adapter
>>>gets reset.
...
>>Please try the attached patch. It adds a sysfs device attribute "allow_restart".
...
> Is it safe to have this attribute be 1 per default, and let the user
> disable it for problematic drives? The IO errors bother me alot...

Matthew Dharm pointed out that it may confuse USB devices:
http://marc.theaimsgroup.com/?l=linux-scsi&m=107702811830956

Side note: May plan for sbp2 is to switch the flag on only for models 
(or, as it is currently done in -mm, for vendor IDs) which are known to 
need the flag. The flag won't hurt with most SBP-2 HDDs; most of them 
don't need it though. But I am worried about how the unknown few quirky 
ones may react. On the other hand, it is likely that MS's SBP-2 stack is 
behaving like Linux with allow_restart=1. I somehow doubt they have a 
whitelist or blacklist for it.

What about enabling it for all direct access and RBC devices, except USB 
direct access devices? (Or equivalently, enable it for all devices in 
scsi/sd but switch it off again in usb-storage?) Or would that be too 
daring?
-- 
Stefan Richter
-=====-=-==- -=== -=-==
http://arcgraph.de/sr/

Re: Fw: SCSI device not spinning up on rw

[Olaf Hering]

 On Tue, Jul 11, Stefan Richter wrote:

> Olaf Hering wrote:
> > On Mon, Jun 05, Brian King wrote:
> >>Brian King wrote:
> ...
> >>>Setting sdev->allow_restart in struct scsi_device will cause sense
> >>>key/code/qual of 02/04/02 (not ready, initialization command required)
> >>>to wake up the scsi error handler and will force scsi core to issue
> >>>a start unit command to the disk. I added this a while back to handle
> >>>ipr raid arrays which need a start unit command each time the adapter
> >>>gets reset.
> ...
> >>Please try the attached patch. It adds a sysfs device attribute 
> >>"allow_restart".
> ...
> >Is it safe to have this attribute be 1 per default, and let the user
> >disable it for problematic drives? The IO errors bother me alot...
> 
> Matthew Dharm pointed out that it may confuse USB devices:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=107702811830956

I found that after I sent this. I'm ok with the current default, it can
be tweaked as needed in the startup scripts.