[...]
Yes, it's just the expiration timer and possibly the interface to user
space that could be considered common code.
Well, the request queue is certainly the most obvious and preferable way
to solve these serialisation issues -- the only drawback being that
other paths might involve less memory allocations, thus reducing
potential issues with paging in when time is of the essence. The
question remains, however, who should be responsible for enqueueing such
a request? And if it is going to be a REQ_TYPE_LINUX_BLOCK request, how
am I supposed to get it past scsi midlayer to the LLDD? But I'll discuss
that particular issue in a seperate mail.
Here is another aspect which I'd like to have your opinion as maintainer
of the block layer about. The more I think about it, the more I am
opposed to the idea to expose a generic queue freezing facility to user
space for *all* block devices. Or rather, I don't consider disk shock
protection an extension, as it were, of such a generic facility. The
reason is simply that I don't see how the two concepts can be generally
compatible. If queue freezing was sufficient for any given application
and for any given block device, then we'd most likely want to freeze the
queue of ATA devices just as we'd do for other devices, i.e., without
disk head unloading. This is because the number of head unloads is
considered an indicator of disk aging.
So, I'd like to export an interface to user space which is specifically
dedicated to disk shock protection, i.e., only available for ATA / IDE
devices. On the other hand, it would be desirable to make this interface
transparent, so user space doesn't have to differentiate between devices
driven by the libata or the ide subsystem. A sysfs attribute
/sys/block/.../queue/protect or even just /sys/block/.../protect would
be very convenient from a user's point of view. However, this would
require something like a blk_register_protect_attr() /
blk_unregister_protect_attr() interface so that libata and ide can
export this attribute for disks after calling blk_init_queue(). Would
that be alright with you? Otherwise, I'd have to implement this
interface directly in the subsystems and *thats* where ioctls seem to be
the easiest way to make this interface as transparent as possible to
user space. In this case a park request of some sort would be fed to the
request queue internally.
Any comments?
Elias
--
