linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott James Remnant <scott@ubuntu.com>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-ide@vger.kernel.org, 114683@bugs.launchpad.net
Subject: Re: Serial ATA (SATA) shutdown info
Date: Tue, 15 May 2007 16:46:32 +0100	[thread overview]
Message-ID: <1179243992.16527.56.camel@quest.netsplit.com> (raw)
In-Reply-To: <711b967b0705150834sdd14538x459119386c19a7ac@mail.gmail.com>

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

On Tue, 2007-05-15 at 17:34 +0200, Tejun Heo wrote:

> Hello, Scott.
> 
Hi, Thanks for your quick reply!

> > Secondly, we've never attempted any workarounds for libata.  Our
> > halt/reboot only iterates /proc/ide, which should be empty for
> > libata-based systems - therefore we've never issued FLUSH CACHE or
> > STANDBYNOW on libata drives from userspace.
> >
> > In this case, how should we proceed?
> >
> >  * Check whether /sys/modules/libata/parameters/spindown_compat exists.
> >    If it does, write 0 to it.
> >
> > Since we've never been broken, can we not arrange for this to be always
> > zero?  Perhaps just writing to it on boot?
> 
> Yes, you can clear that node anytime you want and if your shutdown
> utilities don't issues FLUSH and STANDBY for libata disks on shutdown,
> that's the only thing you'll need to do.  This is still in discussion
> but you might not have to do even that.  Please read the following
> thread.
> 
>   http://article.gmane.org/gmane.linux.ide/18846
> 
> I'll update you when things are determined.  It might be that you
> don't have to do anything.  Sorry about the fuss.
> 
That's no problem, it's good to finally get this stuff cleaned up a
little.  We have an inherent preference for the cleanest and simplest
implementation, obviously :-)  If that means no userspace code, and just
call reboot(), WIN!

> > For each libata harddisk
> >
> >       * Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop
> >         exists. If it doesn't, synchronize cache and spin the disk down
> >         as before. If it does, do nothing and continue to the next disk.
> >         The file is also accessible
> >         as /sys/block/sdX/device/scsi_disk:*/manage_start_stop.
> >
> > What's the reason for needing to flush the cache and standby the disk by
> > hand?  What are the circumstances where the manage_start_stop will not
> > exist?
> 
> On all kernels upto 2.6.21, libata doesn't issue STANDBYNOW on
> shutdown, so some distros including Debian do it during userland
> shutdown.  This isn't a complete solution but most disks don't spin up
> on the following kernel FLUSH, so it's better than not doing anything
> which results in emergency unload for all disks.
> 
Since we've been running with 2.6.x and libata for a while, without
bothering to do this, is there any harm in continuing to not do this?

It's obviously not a regression for us, and we can answer "upgrade to
7.10" quite cheerfully if it turns out there are people with bugs (which
they will have always had).


I'll keep an eye on the thread you linked to, if we don't even need to
write any zeros, we're definitely happy people :-)

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-15 15:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-15 12:42 Serial ATA (SATA) shutdown info Scott James Remnant
2007-05-15 15:34 ` Tejun Heo
2007-05-15 15:46   ` Scott James Remnant [this message]
2007-05-16 10:46     ` Tejun Heo
2007-05-16 12:16       ` Scott James Remnant
2007-05-17  9:18         ` Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2007-09-02  1:37 Alex
2007-09-02 11:41 ` Alex
2007-09-02 12:11   ` Matt Sealey

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=1179243992.16527.56.camel@quest.netsplit.com \
    --to=scott@ubuntu.com \
    --cc=114683@bugs.launchpad.net \
    --cc=htejun@gmail.com \
    --cc=linux-ide@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).