From: Andrew Morton <akpm@osdl.org>
To: Robert Hancock <hancockr@shaw.ca>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC] sd: spin down disks on removal or power-down
Date: Mon, 29 Jan 2007 15:47:06 -0800 [thread overview]
Message-ID: <20070129154706.dfb3edab.akpm@osdl.org> (raw)
In-Reply-To: <45BD522F.3070706@shaw.ca>
On Sun, 28 Jan 2007 19:47:27 -0600
Robert Hancock <hancockr@shaw.ca> wrote:
> Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
> command to stop the drive when the SCSI disk is removed or the machine
> is powered down. The rationale behind this is that apparently on many
> drives, simply cutting power to the spinning disk forces it to do an
> emergency head park/unload which creates more wear on the drive then a
> controlled park/unload with power still applied. This change ensures
> that the drive will be spun down if the user shuts down the machine or
> if they are about to hot-unplug the drive and have done "scsiadd -r" first.
>
> The main potential concern I have about this implementation is that if
> the drive is used in a multi-initiator, iSCSI, etc. environment,
> stopping the drive may be undesirable as another initiator may still be
> accessing it. I'm not familiar enough with these setups to know if this
> problem is likely to come up or not. For this and other reasons we may
> want to make this behavior controllable - I'm open to suggestions on how
> to do this or whether it's needed.
>
> I've tested that this does work on SATA disks through libata (with my
> patch "libata: fix translation for START STOP UNIT" applied). I also
> tested with some external USB-to-IDE drive enclosures. The support for
> START STOP UNIT on those seems rather poor though, on one enclosure with
> a Genesys bridge chip it returned a check condition with "Invalid field
> in CDB", and on another with a JMicron chip the request succeeded but it
> didn't actually spin the drive down.
>
What we don't want to happen is for those disks to spin down during a reboot.
It seems that this is OK with this patch.
Also, we probably don't want them to be spun down during a kexec_load, but
I expect that's OK too.
triviata:
> --- linux-2.6.20-rc6nv/drivers/scsi/sd.c 2007-01-28 17:00:00.000000000 -0600
> +++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c 2007-01-28 18:08:53.000000000 -0600
> @@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
> return res;
> }
>
> +static int sd_stop_unit(struct scsi_device *sdp, struct scsi_disk* sdkp)
s/* / */
> +{
> + int res;
> + struct scsi_sense_hdr sshdr;
> + unsigned char cmd[10] = { 0 };
I don't think this initialisation-to-all-zeroes is needed, is it?
> + if (!scsi_device_online(sdp))
> + return -ENODEV;
> +
> + cmd[0] = START_STOP;
> + /*
> + * Leave the rest of the command zero to indicate
> + * transition to stopped power condition and return
> + * on completion.
> + */
> + printk(KERN_NOTICE "Stopping SCSI disk %s\n",
> + sdkp->disk->disk_name);
> + res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
> + SD_TIMEOUT, SD_MAX_RETRIES);
> +
> + if (res) {
> + printk(KERN_WARNING "sd stop failed: status = %x, message = %02x, "
> + "host = %d, driver = %02x\n",
> + status_byte(res), msg_byte(res),
> + host_byte(res), driver_byte(res));
> + if (driver_byte(res) & DRIVER_SENSE)
> + scsi_print_sense_hdr("sd", &sshdr);
> + }
> +
> + return res;
> +}
> +
> +
> static int sd_issue_flush(struct device *dev, sector_t *error_sector)
> {
> int ret = 0;
> @@ -1727,11 +1760,13 @@ static int sd_probe(struct device *dev)
> **/
> static int sd_remove(struct device *dev)
> {
> + struct scsi_device *sdp = to_scsi_device(dev);
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
>
> class_device_del(&sdkp->cdev);
> del_gendisk(sdkp->disk);
> sd_shutdown(dev);
> + sd_stop_unit(sdp,sdkp);
>
> mutex_lock(&sd_ref_mutex);
> dev_set_drvdata(dev, NULL);
> @@ -1784,6 +1819,9 @@ static void sd_shutdown(struct device *d
> sdkp->disk->disk_name);
> sd_sync_cache(sdp);
> }
> + if(system_state == SYSTEM_POWER_OFF)
s/if(/if (/
> + sd_stop_unit(sdp,sdkp);
> +
> scsi_disk_put(sdkp);
> }
>
>
>
>
>
>
next prev parent reply other threads:[~2007-01-29 23:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 1:47 [PATCH RFC] sd: spin down disks on removal or power-down Robert Hancock
2007-01-29 23:47 ` Andrew Morton [this message]
2007-01-29 23:55 ` Robert Hancock
2007-01-30 0:16 ` James Bottomley
2007-01-30 0:33 ` Robert Hancock
2007-01-31 20:21 ` Stefan Richter
2007-01-31 23:45 ` Robert Hancock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070129154706.dfb3edab.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=hancockr@shaw.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.