Serial ATA (SATA) shutdown info

Serial ATA (SATA) shutdown info

[Scott James Remnant]

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

Hi there,

I'm the author of Upstart (the init system used by Ubuntu, and other
distributions) and was directed to the following page in order to update
compatibility with newer kernels and libata:

	http://linux-ata.org/shutdown.html


Unfortunately after reading this, things still aren't entirely clear to
me.  Right now, Upstart is using roughly the same halt/reboot code as
sysvinit -- this has rather a lot of baggage, so I've been trying to
slim it down recently, and thus reading the same code paths you seem to
have been.

If you could help me through my confusion, that would be greatly
appreciated.


  "In ATA, this is achieved by issuing FLUSH CACHE followed by
   STANDBYNOW and the IDE drivers (drivers/ide/*) have always issued the
   sequence prior to powering off."

This is the code path I've been looking through, and I concur with your
assessment.  IDE drives using the IDE subsystem are powered down (by
generic_ide_suspend() called by ide_device_shutdown)


The sysvinit in Debian (and Upstart in Ubuntu) use the following
procedure during shutdown:

 * sync()
 * Open /proc/ide, iterate all hd* devices found there
 * Check /proc/ide/*/media is "disk"
 * Open the device in /dev
 * Issue WIN_STANDBYNOW1
 * Issue WIN_STANDBYNOW2

No attempt is made to flush the disk cache, other than calling sync().


Firstly, since it appears that the kernel already takes care of flushing
the cache and standbying the disk, it would appear that this code in our
halt/reboot binary is entirely useless.  In some cases this would mean
that the drive was placed into standby, before the kernel flushes its
caches, bringing the drive out of standby with the clicking sound.  (For
the *IDE* subsystem, not libata).

Can we simply drop this code entirely? (I've been of the opinion we can,
but it's nice to get expert confirmation).


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?


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?

Obviously I'd rather our halt/reboot binary was literally a thin wrapper
around the reboot() system call, without special logic.  Since we're
going to have to code the above logic, I'd like to make sure it's going
in the right place.

Also what's the canon way to synchronise the cache and spin the disk
down?  How do we iterate libata harddisks, and map to the correct name
in /dev ?

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 --]

Re: Serial ATA (SATA) shutdown info

[Tejun Heo]

Hello, Scott.

Scott James Remnant wrote:
> The sysvinit in Debian (and Upstart in Ubuntu) use the following
> procedure during shutdown:
>
>  * sync()
>  * Open /proc/ide, iterate all hd* devices found there
>  * Check /proc/ide/*/media is "disk"
>  * Open the device in /dev
>  * Issue WIN_STANDBYNOW1
>  * Issue WIN_STANDBYNOW2
>
> No attempt is made to flush the disk cache, other than calling sync().

Yes, that's exactly why we couldn't implement the workaround entirely
contained in the kernel.  As the userland shutdown issues STANDBYNOW
without preceding FLUSH CACHE, the kernel cannot skip the kernel side
of things.  It's forced to issue FLUSH CACHE and this can spin some
disks back up.

> Firstly, since it appears that the kernel already takes care of flushing
> the cache and standbying the disk, it would appear that this code in our
> halt/reboot binary is entirely useless.  In some cases this would mean
> that the drive was placed into standby, before the kernel flushes its
> caches, bringing the drive out of standby with the clicking sound.  (For
> the *IDE* subsystem, not libata).

Yes.

> Can we simply drop this code entirely? (I've been of the opinion we can,
> but it's nice to get expert confirmation).

Yes, please.

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

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

> Obviously I'd rather our halt/reboot binary was literally a thin wrapper
> around the reboot() system call, without special logic.  Since we're
> going to have to code the above logic, I'd like to make sure it's going
> in the right place.
>
> Also what's the canon way to synchronise the cache and spin the disk
> down?  How do we iterate libata harddisks, and map to the correct name
> in /dev ?

I think the best way is to update the kernel and not to do anything in
userspace - as you said, thin wrapper around the reboot() syscall.

-- 
tejun

Re: Serial ATA (SATA) shutdown info

[Scott James Remnant]

[-- 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 --]

Re: Serial ATA (SATA) shutdown info

[Tejun Heo]

Hello, Scott.

Scott James Remnant wrote:
> 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?

No, I don't think so.

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

If that works for you and your userbase, you don't need to do anything.

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

Me happy too.  :-)

-- 
tejun

Re: Serial ATA (SATA) shutdown info

[Scott James Remnant]

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

On Wed, 2007-05-16 at 12:46 +0200, Tejun Heo wrote:

> > 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 :-)
> 
> Me happy too.  :-)
> 
Out of interest, do you know there is a hysterical need to sync() before
one calls reboot()?

I would have thought the kernel takes care of making sure it's own data
structures are flushed to disk anyway, but I can't see the reference in
the kernel code for where it might do this.

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 --]

Re: Serial ATA (SATA) shutdown info

[Tejun Heo]

Scott James Remnant wrote:
> On Wed, 2007-05-16 at 12:46 +0200, Tejun Heo wrote:
> 
>>> 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 :-)
>> Me happy too.  :-)
>>
> Out of interest, do you know there is a hysterical need to sync() before
> one calls reboot()?
> 
> I would have thought the kernel takes care of making sure it's own data
> structures are flushed to disk anyway, but I can't see the reference in
> the kernel code for where it might do this.

I dunno.  I seem to recall there was discussion about disk driver not
flushing cache or something like that years ago but I could be imagining
things.  With recent kernels, there's no reason for userland to do that
before shutting down.  Kernel always flushes caches during shutdown, but
we can also afford some paranoia there as that doesn't cause any harm.

-- 
tejun

Serial ATA (SATA) shutdown info

[Alex]

Hi!

I'm Debian Linux distro user and when my computer go down it was saying to 
update my shutdown utility and this url: http://linux-ata.org/shutdown.html

I wrote this e-mail to you to inform that when I update the Debian distro 
yesterday (01-Sep-2007) the message disappears, if I'm not wrong Debian distro 
have now update the shutdown. If you confirm my words, can you update the part 
of the web that say there isn't any distro updated yet? Debian's user will be 
happy to update they distro's simply with apt-get utility ;)

Thanks!

Alex
http://counter.li.org/cgi-bin/certificate.cgi/411619

Re: Serial ATA (SATA) shutdown info

[Alex]

I'm sorry, but another time the message appears, I don't understand, sorry but 
the shutdown isn't updated at Debian.

Alex
http://counter.li.org/cgi-bin/certificate.cgi/411619

Alex escribió:
> Hi!
> 
> I'm Debian Linux distro user and when my computer go down it was saying 
> to update my shutdown utility and this url: 
> http://linux-ata.org/shutdown.html
> 
> I wrote this e-mail to you to inform that when I update the Debian 
> distro yesterday (01-Sep-2007) the message disappears, if I'm not wrong 
> Debian distro have now update the shutdown. If you confirm my words, can 
> you update the part of the web that say there isn't any distro updated 
> yet? Debian's user will be happy to update they distro's simply with 
> apt-get utility ;)
> 
> Thanks!
> 
> Alex
> http://counter.li.org/cgi-bin/certificate.cgi/411619
> 

Re: Serial ATA (SATA) shutdown info

[Matt Sealey]

I think Debian updated the shutdown utility in experimental/testing already
(and Gentoo seems to have a patch in portage, but it's masked). Every distro
is doing a different thing, but none of the support is anything people are
going to push to the current set of systems.

Part of the problem is everyone is basing "last year"'s distros off "last
year"'s kernels (2.6.18, 2.6.19, 2.6.20) which do not have the shutdown
changes. If you update to the very latest kernel, you are in fact on your
own.

Ubuntu Gutsy (about a month away), openSUSE 10.3 (about a month away) and
the next Fedora Core work fine, as they have a need to (affected kernel
and userland combination) but current distros like Etch, Hoary, 10.2 and
Fedora Core 7 just have no reason to update for the vast majority of
users and their unaffected standard kernels.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Alex wrote:
> I'm sorry, but another time the message appears, I don't understand, 
> sorry but the shutdown isn't updated at Debian.
> 
> Alex
> http://counter.li.org/cgi-bin/certificate.cgi/411619
> 
> Alex escribió:
>> Hi!
>>
>> I'm Debian Linux distro user and when my computer go down it was 
>> saying to update my shutdown utility and this url: 
>> http://linux-ata.org/shutdown.html
>>
>> I wrote this e-mail to you to inform that when I update the Debian 
>> distro yesterday (01-Sep-2007) the message disappears, if I'm not 
>> wrong Debian distro have now update the shutdown. If you confirm my 
>> words, can you update the part of the web that say there isn't any 
>> distro updated yet? Debian's user will be happy to update they 
>> distro's simply with apt-get utility ;)
>>
>> Thanks!
>>
>> Alex
>> http://counter.li.org/cgi-bin/certificate.cgi/411619
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html