One of the many features which will be shipped with the 2.6.14 kernel will
be a driver for the "hard drive active protection system" found in some
ThinkPad laptops. This system provides a set of sensors, and, in
particular, an accelerometer which can report on the position of the laptop
- and how quickly that position is changing. There are a number of
applications of such device - such as a version of neverball
played by tipping the laptop. The real purpose, however, is to enable the
system to react to a fall and attempt to protect the hard drive.
The next step in the implementation of that purpose is the hard drive protection patch
recently posted by Jon Escombe. This patch adds two new callbacks to the
block request queue which drivers can provide:
typedef int (issue_protect_fn) (request_queue_t *);
typedef int (issue_unprotect_fn) (request_queue_t *);
If the driver provides these functions, the request queue, as seen in
sysfs, will contain a new protect attribute. If a value is
written to that attribute, the block system will interpret it as an integer
number of seconds. The issue_protect_fn() will be called, and the
request queue will be plugged for the indicated number of seconds. When
that time expires, issue_unprotect_fn() will be called and the
queue will be restarted.
The theory of operation here is that a user-space daemon will be monitoring
the status of the system, as reported by the accelerometer. Should this
daemon note that the laptop has begun to accelerate, it will quickly write
a value to the protect attribute for each drive in the system.
The drives will respond by parking the disk heads, and, in any other
possible way, telling the drive to crawl into its shell and prepare for
impact. Once the event has transpired, the shattered remains of the laptop
can attempt to resume normal operation.
The idea seems reasonable, but block maintainer Jens Axboe has turned down the patch for now. Says Jens:
We have far too many queue hooks already, adding two more for a
relatively obscure use such as this one is not a good idea.
The number of request queue callbacks is indeed large. Some of them have
little to do with drivers (there's one which is called whenever disk
activity happens, for example; it can be used to flash a keyboard LED in
the absence of a hardware disk activity light), but others, such as the
ones discussed here, are direct requests to the underlying block driver.
The use of callbacks seems a little redundant in this situation, given that
the request queue is, fundamentally, a mechanism for conveying commands to
block drivers. The right solution might thus be to use the request queue
to carry commands beyond those requesting the movement of blocks to and
from the drive.
To an extent, the request queue is already used this way. Packet commands,
ATA task file commands, and power management commands can be fed to drivers
through the queue. In each case, the flags field of struct
request is used to indicate that something special is being
requested. The use of flags in this way is getting a little
unwieldy, however, leading to the consideration of a new approach.
That approach, as seen in a patch held by Jens, is to add a new field
(cmd_type) to struct request which indicates the type of
command embodied by each request. Currently-anticipated types include
packet commands, sense requests, power management commands, flush requests,
driver-specific special requests, and Linux-specific, generic requests.
Oh, and the occasional request to move a disk block in one direction or the
other. The addition of cmd_type turns struct request
into a generic carrier of commands to a disk drive.
With this mechanism in place, the "brace yourself, we're falling!" message
becomes just another Linux-specific block request type. When such an event
happens, the kernel need only place one of those messages on the queue -
preferably at the head of the queue - and call the driver's
request() function. The driver can then prepare the drive for the
coming catastrophe and plug the queue itself. No additional callbacks
This approach does involve some significant changes to the block layer,
however, and would include a driver API change. So it is not likely to
take a quick path into the kernel. The hard drive protection mechanism,
which will require the new API, thus looks likely to wait in line for a
to post comments)