LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Soeren Sonnenburg <kernel@nn7.de>
Cc: Tejun Heo <htejun@gmail.com>, Jeff Garzik <jeff@garzik.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: SATA hotplug from the user side ?
Date: Wed, 24 Jan 2007 13:37:27 -0200	[thread overview]
Message-ID: <20070124153727.GC15402@khazad-dum.debian.net> (raw)
In-Reply-To: <1169629789.3779.3.camel@localhost>

On Wed, 24 Jan 2007, Soeren Sonnenburg wrote:
> might be a good idea to power down the drive using hdparm -Y followed by
> a scsiadd -r.

Unfortunately, I don't think this will be the optimal way to do it for long.
Unless I am mistaken, the above will soon have the potential to spin down
the device, and then reset the device to wake it up again (through error
handling, thus causing error messages in syslog) to send it a spin down
command(!).  It will work well right now, because scsiadd -r is unable to
shutdown a device and just removes it.

In the future, you will need to do *either* one, not both, if you told the
kernel to shutdown SCSI devices (which distros will likely enable by
default, as it is the right setup for everyone but people with servers
with disks attached to multi-initiator SCSI buses and it is required for
suspend-to-disk to work).

It will be a mess to make sure everything in userspace is updated to not try
to hdparm -y (or worse, hdparm -Y) devices that the kernel will shutdown by
itself, but it will make things a lot better for the future.

Unless...

Tejun, is it feasible to teach libata to check the device power management
state before issuing any of the sleep, head unload and spin-down commands?

libata would need to block its EH from resetting a channel for this check
operation (we don't want to wake up sleeping devices to ask it if it is
sleeping...) if it cannot easily check if an device is asleep before issuing
a command to it.   Either that, or (for as long as there is no such a thing
as a multi-initiator libata device) just keep track of the device power
management state by snooping all the commands sent to it.

The idea would be to do the "optimal" thing if one tries to sleep, unload
heads or spin down an device that is already doing one of these things...
That would make things MUCH easier on userspace.

> BIG FAT WARNING: if your SATA bay does not do electrical connector
> keying to let the disk firmware unload heads before the user manages to

This either is in the SATA specification, or it is not, and according to
Tejun it probably isn't (if it were, all disks would do the right thing at
unplug).  I'd reword it to "if your SATA bay does not take extra steps to
force the disk firmware to unload heads...".

> the disk or remove the disk from a dm setup). However it is recommended
> to power down the drive using hdparm -Y followed by a scsiadd -r as
> stated above. One can validate which disks are attached using ``scsiadd

Again, this might change soon.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2007-01-24 15:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-12  7:57 Soeren Sonnenburg
2007-01-12 17:04 ` Jeff Garzik
2007-01-12 22:07   ` Soeren Sonnenburg
2007-01-13  1:55     ` Tejun Heo
2007-01-13  7:22       ` Soeren Sonnenburg
2007-01-15  2:21         ` Tejun Heo
2007-01-22  9:04           ` Soeren Sonnenburg
2007-01-22 21:03             ` Henrique de Moraes Holschuh
2007-01-23  6:23               ` Tejun Heo
2007-01-23 13:10                 ` Henrique de Moraes Holschuh
2007-01-24  2:07                   ` Tejun Heo
2007-01-24  9:09                     ` Soeren Sonnenburg
2007-01-24 15:37                       ` Henrique de Moraes Holschuh [this message]
2007-01-25 12:56                         ` Soeren Sonnenburg
2007-01-25 21:56                           ` Henrique de Moraes Holschuh
2007-01-25 21:21                         ` Eric D. Mudama
2007-02-05 11:56                           ` Tejun Heo
2007-02-05 11:50                         ` Tejun Heo
2007-01-23  6:19             ` Tejun Heo
     [not found] <fa.pn1gmGiSlhDVMiPyzEEm1A66vcY@ifi.uio.no>
     [not found] ` <fa.Od11QHN89ZQ9VkFktF6HvxWuLV0@ifi.uio.no>
     [not found]   ` <fa.vsuV8EVipw4cXaHgzWpaf0q1pAA@ifi.uio.no>
     [not found]     ` <fa.8a1kVu4a2ISeaFZcL3migbjZ5N0@ifi.uio.no>
     [not found]       ` <fa.79JzgEcD2u5B9SYqrw3sr5b+iy8@ifi.uio.no>
     [not found]         ` <fa.DH50RMz6OHKG0AoGA/cChsCW8Ig@ifi.uio.no>
2007-01-25  0:33           ` 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=20070124153727.GC15402@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=kernel@nn7.de \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: SATA hotplug from the user side ?' \
    /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

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