From: Tejun Heo <htejun@gmail.com>
To: dougg@torque.net
Cc: James.Bottomley@SteelEye.com, Jeff Garzik <jgarzik@pobox.com>,
hmh@hmh.eng.br, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH] sd: implement stop_on_shutdown
Date: Sat, 20 Jan 2007 12:18:42 +0900 [thread overview]
Message-ID: <45B18A12.5060605@gmail.com> (raw)
In-Reply-To: <45B15575.5090806@torque.net>
Hello, Douglas.
Douglas Gilbert wrote:
>> This patch implements sd attribute stop_on_shutdown. If set to 1, sd
>> stops the drive on non-restarting shutdown. stop_on_shutdown is
>> initialized from sd parameter stop_on_shutdown_default which defaults
>> to 0. So, this patch does not change the default behavior.
>
> Tejun,
> The IMMED bit in the START STOP UNIT cdb is not being set
> when your patch stops a drive:
>
> Advantage:
> - the power won't be dropped immediately after sending
> the command to the drive (assuming the drive gets
> its power from the same power supply that shutdown
> turns off)
>
> Disadvantage:
> - it will delay shutdown proportional to the number of
> drives with the stop_on_shutdown attribute set. Say
> 5 seconds per disk.
We pretty much need the IMMED bit to be cleared. The goal of this patch
is to allow drives unload their heads before power is cut off and with
IMMED set, we really don't know when is safe to power off the machine.
> Disadvantage (with or without IMMED bit set):
> - if another initiator (e.g. on another machine) was
> using a different partition on that disk, then it might
> get upset (especially if it was running Linux).
> [I'm not sure why you say this patch is necessary
> in this case.]
Yeap, I agree with you. I don't think the behavior introduced by this
patch is necessary in that case (did I say otherwise?) and that's
precisely why the default behavior hasn't been changed. This is just
for small little machines running SATA and possibly USB disks (dunno
their SAT implement START_STOP tho) which are currently having problems
shutting down its disks on sleep to disk and sometimes poweroff.
> BTW SCSI disks typically have a lower start-stop lifetime
> rating than ATA disks. This reflects that SCSI disks are
> designed to be on 168 hours per week.
Yeap, not as useful as for PC stuff but I think having and enabling this
still would help in single initiator cases. As you just said, they are
rated for less load-unload lifetime to begin with.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-01-20 3:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-19 17:01 [PATCH] sd: implement stop_on_shutdown Tejun Heo
2007-01-19 23:34 ` Douglas Gilbert
2007-01-20 3:18 ` Tejun Heo [this message]
2007-01-21 22:47 ` Stefan Richter
2007-01-19 23:42 ` Darrick J. Wong
2007-01-20 3:22 ` Tejun Heo
2007-01-20 9:50 ` Jeff Garzik
2007-01-20 9:59 ` Tejun Heo
2007-01-20 14:39 ` James Bottomley
2007-01-20 14:39 ` James Bottomley
2007-02-05 9:43 ` Tejun Heo
2007-02-05 14:55 ` James Bottomley
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=45B18A12.5060605@gmail.com \
--to=htejun@gmail.com \
--cc=James.Bottomley@SteelEye.com \
--cc=dougg@torque.net \
--cc=hmh@hmh.eng.br \
--cc=jgarzik@pobox.com \
--cc=linux-ide@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).