LKML Archive on
help / color / mirror / Atom feed
From: Elias Oltmanns <>
To: Bartlomiej Zolnierkiewicz <>,
	Jeff Garzik <>,
	Randy Dunlap <>,
	Tejun Heo <>
Subject: [PATCH 4/4 v2] Add documentation for hard disk shock protection interface
Date: Wed, 17 Sep 2008 18:40:06 +0200	[thread overview]
Message-ID: <20080917163145.9870.8575.stgit@denkblock.local> (raw)
In-Reply-To: <87d4j2n3dn.fsf@denkblock.local>

Put some information (and pointers to more) into the kernel's doc tree,
describing briefly the interface to the kernel's disk head unloading
facility. Information about how to set up a complete shock protection
system under GNU/Linux can be found on the web and is referenced

Signed-off-by: Elias Oltmanns <>

 Documentation/laptops/disk-shock-protection.txt |  144 +++++++++++++++++++++++
 1 files changed, 144 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/laptops/disk-shock-protection.txt

diff --git a/Documentation/laptops/disk-shock-protection.txt b/Documentation/laptops/disk-shock-protection.txt
new file mode 100644
index 0000000..1f93462
--- /dev/null
+++ b/Documentation/laptops/disk-shock-protection.txt
@@ -0,0 +1,144 @@
+Hard disk shock protection
+Author: Elias Oltmanns <>
+Last modified: 2008-09-16
+0. Contents
+1. Intro
+2. The interface
+3. References
+1. Intro
+ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature.
+Issuing this command should cause the drive to switch to idle mode and
+unload disk heads. This feature is being used in modern laptops in
+conjunction with accelerometers and appropriate software to implement
+a shock protection facility. The idea is to stop all I/O operations on
+the internal hard drive and park its heads on the ramp when critical
+situations are anticipated. The desire to have such a feature
+available on GNU/Linux systems has been the original motivation to
+implement a generic disk head parking interface in the Linux kernel.
+Please note, however, that other components have to be set up on your
+system in order to get disk shock protection working (see section
+3. References below for pointers to more information about that).
+2. The interface
+For each ATA device the kernel exports the file
+block/*/device/unload_heads in sysfs (here assumed to be mounted under
+/sys). Access to /sys/block/*/device/unload_heads is denied with
+-EOPNOTSUPP if the device does not support the unload feature.
+Otherwise, writing an integer value to file will take the heads of the
+respective drive off the platter and block all I/O operations for the
+specified number of milliseconds. When the timeout expires and no
+further disk head park request has been issued in the meantime, normal
+operation will be resumed. The maximal value accepted for a timeout is
+30000 milliseconds. Exceeding this limit will return -EOVERFLOW, but
+heads will be parked anyway and the timeout will be set to 30 seconds.
+However, you can always change a timeout to any value between 0 and
+30000 by issuing a subsequent head park request before the timeout of
+the previous one has expired. In particular, the total timeout can
+exceed 30 seconds and, more importantly, you can cancel a previously
+set timeout and resume normal operation immediately by specifying a
+timeout of 0. Values below -2 are rejected with -EINVAL (see below for
+the special meaning of -1 and -2). If the timeout specified for a
+recent head park request has not yet expired, reading from
+/sys/block/*/device/unload_heads will report the number of
+milliseconds remaining until normal operation will be resumed;
+otherwise, reading the unload_heads attribute will return 0.
+For example, do the following in order to park the heads of drive
+/dev/sda and stop all I/O operations for five seconds:
+# echo 5000 > /sys/block/sda/device/unload_heads
+A simple
+# cat /sys/block/sda/device/unload_heads
+will show you how many milliseconds are left before normal operation
+will be resumed.
+There is a technical detail of this implementation that may cause some
+confusion and should be discussed here. When a head park request has
+been issued to a device successfully, all I/O operations on the
+controller port this device is attached to will be deferred. That is
+to say, any other device that may be connected to the same port will
+be affected too. The only exception is that a subsequent head unload
+request to that other devvice will be executed immediately. Further
+operations on that port will be deferred until the timeout specified
+for either device on the port has expired. As far as PATA (old style
+IDE) configurations are concerned, there can only be two devices
+attached to any single port. In SATA world we have port multipliers
+which means that a user issued head parking request to one device may
+actually result in stopping I/O to a whole bunch of devices. Hwoever,
+since this feature is supposed to be used on laptops and does not seem
+to be very useful in any other environment, there will be mostly one
+device per port. Even if the CD/DVD writer happens to be connected to
+the same port as the hard drive, it generally *should* recover just
+fine from the occasional buffer under-run incurred by a head park
+request to the HD. Actually, when you are using an ide driver rather
+than it's libata counterpart (i.e. your disk is called /dev/hda
+instead of /dev/sda), then parking the heads of drive A will generally
+not affect the mode of operation of drive B on the same port as
+described above. It is only when a port reset is required to recover
+from an exception on drive B that further I/O operations on that drive
+(and the reset itself) will be delayed until drive A is no longer in
+the parked state.
+Finally, there are some hard drives that only comply with an earlier
+version of the ATA standard than ATA-7, but do support the unload
+feature nonetheless. Unfortunately, there is no safe way Linux can
+detect these devices, so you won't be able to write to the
+unload_heads attribute. If you know that your device really does
+support the unload feature (for instance, because the vendor of your
+laptop or the hard drive itself told you so), then you can tell the
+kernel to enable the usage of this feature for that drive by writing
+the special value -1 to the unload_heads attribute:
+# echo -1 > /sys/block/sda/device/unload_heads
+will enable the feature for /dev/sda, and giving -2 instead of -1 will
+disable it again.
+3. References
+There are several laptops from different vendors featuring shock
+protection capabilities. As manufacturers have refused to support open
+source development of the required software components so far, Linux
+support for shock protection varies considerably between different
+hardware implementations. Ideally, this section should contain a list
+of pointers at different projects aiming at an implementation of shock
+protection on different systeems. Unfortunately, I only know of a
+single project which, although still considered experimental, is fit
+for use. Please feel free to add projects that have been the victims
+of my ignorance.
+  See this page for information about Linux support of the hard disk
+  active protection system as implemented in IBM/Lenovo Thinkpads.
+  (FIXME: The information there will have to be updated once this
+  patch has been approved or the user interface has been agreed upon
+  at least.)
+This implementation of disk head parking has been inspired by a patch
+originally published by Jon Escombe <>. My efforts
+to develop an implementation of this feature that is fit to be merged
+into mainline have been aided by various kernel developers, in
+particular by Tejun Heo and Bartlomiej Zolnierkiewicz.

  parent reply	other threads:[~2008-09-17 16:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17 16:28 Disk shock protection in GNU/Linux Elias Oltmanns
2008-09-17 16:34 ` [PATCH 1/4 v2] Introduce ata_id_has_unload() Elias Oltmanns
2008-09-17 16:57   ` Tejun Heo
2008-09-18 23:24     ` Bartlomiej Zolnierkiewicz
2008-09-17 16:37 ` [PATCH 2/4 v2] libata: Implement disk shock protection support Elias Oltmanns
2008-09-17 18:03   ` Tejun Heo
2008-09-17 18:08   ` Tejun Heo
2008-09-17 18:09   ` Tejun Heo
2008-09-19  9:49     ` Elias Oltmanns
2008-09-19 12:14       ` Tejun Heo
2008-09-19 14:06         ` Elias Oltmanns
2008-09-19 14:15           ` Tejun Heo
2008-09-19 15:00             ` Elias Oltmanns
2008-09-20  4:48               ` Tejun Heo
2008-09-17 16:38 ` [PATCH 3/4 v2] ide: " Elias Oltmanns
2008-09-18 23:24   ` Bartlomiej Zolnierkiewicz
2008-09-19  0:28     ` Elias Oltmanns
2008-09-19  0:47       ` Bartlomiej Zolnierkiewicz
2008-10-04  9:44     ` Elias Oltmanns
2008-10-04 13:49       ` Elias Oltmanns
2008-10-04 23:16         ` Elias Oltmanns
2008-10-08 18:56           ` Bartlomiej Zolnierkiewicz
2008-09-17 16:40 ` Elias Oltmanns [this message]
2008-09-18 23:28   ` [PATCH 4/4 v2] Add documentation for hard disk shock protection interface Bartlomiej Zolnierkiewicz
2008-10-04  9:55     ` Elias Oltmanns
2008-10-08 18:56       ` Bartlomiej Zolnierkiewicz
2008-09-19  4:21   ` Grant Grundler
2008-09-19 12:08     ` Elias Oltmanns

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080917163145.9870.8575.stgit@denkblock.local \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 4/4 v2] Add documentation for hard disk shock protection interface' \

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