New libata/scsi spindown functionality in 2.6.22 requires changes in userland shutdown(8)

Bug #114683 reported by Francesco Pretto on 2007-05-14
6
Affects Status Importance Assigned to Milestone
upstart
Undecided
Unassigned

Bug Description

As from linux kernel version 2.6.22-rc1, a refactored suspend and resume support for ata disks has been merged [1] [2]. Lack of feature on prior kernels libata drivers and incorrect behavior on userland tools are causing anomalous head parking noises on a considerably number of hard disks, as various bug reports appeared in the web [3] [4]. This is not only an annoying problem but it's considered a possible risk of reduced hard disk lifespan (especially for laptop users). A page in the linux-ata home site has been set up in the to assist userland init tools developers in the migration [5].

The following extract by Tejun Heo, the author of the concerning kernel patches, illustrate the approach that should adopted in updated shutdown(8)/halt(8) implementations.

> * Check whether /sys/modules/libata/parameters/spindown_compat
> exists. If it does, write 0 to it.
>
> * For each libata harddisk {
> * Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop
> exists. Iff it doesn't, synchronize cache and spin the disk
> down as before.
> }

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9666f4009c22f6520ac3fb8a19c9e32ab973e828
[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=920a4b1038e442700a1cfac77ea7e20bd615a2c3
[3] https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/67810
[4] http://bugzilla.kernel.org/show_bug.cgi?id=7674
[5] http://linux-ata.org/shutdown.html

Changed in upstart:
status: Unconfirmed → Confirmed
Download full text (3.2 KiB)

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

Read more...

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
<email address hidden>

Francesco Pretto (ceztko) wrote :

I've seen you got a personal reply from Tejun Heo. That's good!

For everybody else, these are the right threads where continue the discussion, including the already linked one:

Gentoo sysvinit maintainer observations:
http://thread.gmane.org/gmane.linux.ide/18840

Proposed patch that require no userland modifications on sysvinit inherited implementations:
http://thread.gmane.org/gmane.linux.ide/18846

Tormod Volden (tormodvolden) 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?
> It's obviously not a regression for us,

Scott, I hope you are aware of all the complaints and bug reports about hard disks screaming at shutdown since libata came into Edgy and Feisty, see bug #67810.

Tormod, as far as we know, that bug only affects people using the ide subsystem and not the libata subsystem.

And as you'll read above, we've tracked the problem to the *inverse* of the libata issue documented and it looks like we have a handle on the fix.

Tormod Volden (tormodvolden) wrote :

My Compaq (with "via" chipset) made this disk noise early in Feisty when it was using ata/pata (and the disk was /dev/sda). Before and after it is quiet, using ide/pci/via82cxxx.ko (on /dev/hda). My Acer also makes this noise, it's using libata/ata_piix (on /dev/sda). But maybe I mix up the nomenclature. The workaround that worked for most (all?) people was echo 1 > /sys/class/scsi_disk/0\:0\:0\:0/stop_on_shutdown.

On Tue, 2007-05-15 at 20:38 +0000, Tormod Volden wrote:

> My Compaq (with "via" chipset) made this disk noise early in Feisty when
> it was using ata/pata (and the disk was /dev/sda). Before and after it
> is quiet, using ide/pci/via82cxxx.ko (on /dev/hda). My Acer also makes
> this noise, it's using libata/ata_piix (on /dev/sda). But maybe I mix up
> the nomenclature. The workaround that worked for most (all?) people was
> echo 1 > /sys/class/scsi_disk/0\:0\:0\:0/stop_on_shutdown.
>
And the kernel patch being discussed here will remove the need for that.

So all is shiny and happy.

Scott
--
Scott James Remnant
Ubuntu Development Manager
<email address hidden>

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
<email address hidden>

As discussed with the libata upstream, we don't need to change our /sbin/reboot utility at all. The 2.6.22 kernel will notice that we have made no attempt to flush the caches or shutdown the disk, and will perform it for us.

Changed in upstart:
status: Confirmed → Rejected
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers