Re: [PATCH 4/4] libata: implement libata.spindown_compat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tejun Heo wrote:
Now that libata uses sd->manage_start_stop, libata spins down disk on
shutdown.  In an attempt to compensate libata's previous shortcoming,
shutdown(8) syncs and spins down disks attached via libata.  Some
disks spin back up just to spin down again on STANDBYNOW1 if the
command is issued when the disk is spun down, so this double spinning
down causes problem.

This patch implements module parameter libata.spindown_compat which,
when set to one (default value), prevents libata from spinning down
disks on shutdown thus avoiding double spinning down.  Note that
libata spins down disks for suspend to mem and disk, so with
libata.spindown_compat set to one, disks should be properly spun down
in all cases without modifying shutdown(8).

shutdown(8) should be fixed eventually tho.  Some drive do spin up on
SYNCHRONZE_CACHE even when their cache is clean.  Those disks
currently spin up briefly when sd tries to shutdown the device and
then the machine powers off immediately, which can't be good for the
head.  We can't skip SYNCHRONIZE_CACHE during shudown as it can be
dangerous data integrity-wise.

So, this spindown_compat parameter is already scheduled for removal by
the end of the next year and here's what shutdown(8) should do.

  1. Check whether /sys/modules/libata/parameters/spindown_compat
     exists.  If it does, write 0 to it.

  For each libata harddisk {

    2. Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop
       exists.  If so, write 1 to it and continue; otherwise, fall
       through to #3.

    3. Synchronize cache and spin down as before.

  }

Signed-off-by: Tejun Heo <htejun@xxxxxxxxx>
---
Henrique, does it look good enough?  How do we coordinate this with
distributions?  I can take care of suse and I guess Alan/Jeff can do
so for redhat.  So, that leaves us with Debian, Ubuntu, Gentoo...

ACK patches 3-4 for upstream. I'm dropping them, and requesting resend when patches 1-2 are applied (which I also ACK). Or, alternately, I could apply all four patches with the other subsystem owner's assent, or the other subsystem owner could apply all four patches now that I have ACK'd them. Pick any of the three options. :)

	Jeff





-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux