Elias Oltmanns | 9c6102d | 2008-10-13 21:39:50 +0200 | [diff] [blame] | 1 | Hard disk shock protection |
| 2 | ========================== |
| 3 | |
| 4 | Author: Elias Oltmanns <eo@nebensachen.de> |
| 5 | Last modified: 2008-10-03 |
| 6 | |
| 7 | |
| 8 | 0. Contents |
| 9 | ----------- |
| 10 | |
| 11 | 1. Intro |
| 12 | 2. The interface |
| 13 | 3. References |
| 14 | 4. CREDITS |
| 15 | |
| 16 | |
| 17 | 1. Intro |
| 18 | -------- |
| 19 | |
| 20 | ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature. |
| 21 | Issuing this command should cause the drive to switch to idle mode and |
| 22 | unload disk heads. This feature is being used in modern laptops in |
| 23 | conjunction with accelerometers and appropriate software to implement |
| 24 | a shock protection facility. The idea is to stop all I/O operations on |
| 25 | the internal hard drive and park its heads on the ramp when critical |
| 26 | situations are anticipated. The desire to have such a feature |
| 27 | available on GNU/Linux systems has been the original motivation to |
| 28 | implement a generic disk head parking interface in the Linux kernel. |
| 29 | Please note, however, that other components have to be set up on your |
| 30 | system in order to get disk shock protection working (see |
| 31 | section 3. References below for pointers to more information about |
| 32 | that). |
| 33 | |
| 34 | |
| 35 | 2. The interface |
| 36 | ---------------- |
| 37 | |
| 38 | For each ATA device, the kernel exports the file |
| 39 | block/*/device/unload_heads in sysfs (here assumed to be mounted under |
| 40 | /sys). Access to /sys/block/*/device/unload_heads is denied with |
| 41 | -EOPNOTSUPP if the device does not support the unload feature. |
| 42 | Otherwise, writing an integer value to this file will take the heads |
| 43 | of the respective drive off the platter and block all I/O operations |
| 44 | for the specified number of milliseconds. When the timeout expires and |
| 45 | no further disk head park request has been issued in the meantime, |
| 46 | normal operation will be resumed. The maximal value accepted for a |
| 47 | timeout is 30000 milliseconds. Exceeding this limit will return |
| 48 | -EOVERFLOW, but heads will be parked anyway and the timeout will be |
| 49 | set to 30 seconds. However, you can always change a timeout to any |
| 50 | value between 0 and 30000 by issuing a subsequent head park request |
| 51 | before the timeout of the previous one has expired. In particular, the |
| 52 | total timeout can exceed 30 seconds and, more importantly, you can |
| 53 | cancel a previously set timeout and resume normal operation |
| 54 | immediately by specifying a timeout of 0. Values below -2 are rejected |
| 55 | with -EINVAL (see below for the special meaning of -1 and -2). If the |
| 56 | timeout specified for a recent head park request has not yet expired, |
| 57 | reading from /sys/block/*/device/unload_heads will report the number |
| 58 | of milliseconds remaining until normal operation will be resumed; |
| 59 | otherwise, reading the unload_heads attribute will return 0. |
| 60 | |
| 61 | For example, do the following in order to park the heads of drive |
| 62 | /dev/sda and stop all I/O operations for five seconds: |
| 63 | |
| 64 | # echo 5000 > /sys/block/sda/device/unload_heads |
| 65 | |
| 66 | A simple |
| 67 | |
| 68 | # cat /sys/block/sda/device/unload_heads |
| 69 | |
| 70 | will show you how many milliseconds are left before normal operation |
| 71 | will be resumed. |
| 72 | |
| 73 | A word of caution: The fact that the interface operates on a basis of |
| 74 | milliseconds may raise expectations that cannot be satisfied in |
| 75 | reality. In fact, the ATA specs clearly state that the time for an |
| 76 | unload operation to complete is vendor specific. The hint in ATA-7 |
| 77 | that this will typically be within 500 milliseconds apparently has |
| 78 | been dropped in ATA-8. |
| 79 | |
| 80 | There is a technical detail of this implementation that may cause some |
| 81 | confusion and should be discussed here. When a head park request has |
| 82 | been issued to a device successfully, all I/O operations on the |
| 83 | controller port this device is attached to will be deferred. That is |
| 84 | to say, any other device that may be connected to the same port will |
| 85 | be affected too. The only exception is that a subsequent head unload |
| 86 | request to that other device will be executed immediately. Further |
| 87 | operations on that port will be deferred until the timeout specified |
| 88 | for either device on the port has expired. As far as PATA (old style |
| 89 | IDE) configurations are concerned, there can only be two devices |
| 90 | attached to any single port. In SATA world we have port multipliers |
| 91 | which means that a user-issued head parking request to one device may |
| 92 | actually result in stopping I/O to a whole bunch of devices. However, |
| 93 | since this feature is supposed to be used on laptops and does not seem |
| 94 | to be very useful in any other environment, there will be mostly one |
| 95 | device per port. Even if the CD/DVD writer happens to be connected to |
| 96 | the same port as the hard drive, it generally *should* recover just |
| 97 | fine from the occasional buffer under-run incurred by a head park |
| 98 | request to the HD. Actually, when you are using an ide driver rather |
| 99 | than its libata counterpart (i.e. your disk is called /dev/hda |
| 100 | instead of /dev/sda), then parking the heads of one drive (drive X) |
| 101 | will generally not affect the mode of operation of another drive |
| 102 | (drive Y) on the same port as described above. It is only when a port |
| 103 | reset is required to recover from an exception on drive Y that further |
| 104 | I/O operations on that drive (and the reset itself) will be delayed |
| 105 | until drive X is no longer in the parked state. |
| 106 | |
| 107 | Finally, there are some hard drives that only comply with an earlier |
| 108 | version of the ATA standard than ATA-7, but do support the unload |
| 109 | feature nonetheless. Unfortunately, there is no safe way Linux can |
| 110 | detect these devices, so you won't be able to write to the |
| 111 | unload_heads attribute. If you know that your device really does |
| 112 | support the unload feature (for instance, because the vendor of your |
| 113 | laptop or the hard drive itself told you so), then you can tell the |
| 114 | kernel to enable the usage of this feature for that drive by writing |
| 115 | the special value -1 to the unload_heads attribute: |
| 116 | |
| 117 | # echo -1 > /sys/block/sda/device/unload_heads |
| 118 | |
| 119 | will enable the feature for /dev/sda, and giving -2 instead of -1 will |
| 120 | disable it again. |
| 121 | |
| 122 | |
| 123 | 3. References |
| 124 | ------------- |
| 125 | |
| 126 | There are several laptops from different vendors featuring shock |
| 127 | protection capabilities. As manufacturers have refused to support open |
| 128 | source development of the required software components so far, Linux |
| 129 | support for shock protection varies considerably between different |
| 130 | hardware implementations. Ideally, this section should contain a list |
| 131 | of pointers at different projects aiming at an implementation of shock |
| 132 | protection on different systems. Unfortunately, I only know of a |
| 133 | single project which, although still considered experimental, is fit |
| 134 | for use. Please feel free to add projects that have been the victims |
| 135 | of my ignorance. |
| 136 | |
| 137 | - http://www.thinkwiki.org/wiki/HDAPS |
| 138 | See this page for information about Linux support of the hard disk |
| 139 | active protection system as implemented in IBM/Lenovo Thinkpads. |
| 140 | |
| 141 | |
| 142 | 4. CREDITS |
| 143 | ---------- |
| 144 | |
| 145 | This implementation of disk head parking has been inspired by a patch |
| 146 | originally published by Jon Escombe <lists@dresco.co.uk>. My efforts |
| 147 | to develop an implementation of this feature that is fit to be merged |
| 148 | into mainline have been aided by various kernel developers, in |
| 149 | particular by Tejun Heo and Bartlomiej Zolnierkiewicz. |