I would like to submit the latest disk protection (a.k.a. parking and
freezing) code from the hdaps-devel side for comment, along with a brief
overview of what's in the patch -
During initialisation, disk drivers with 'protect' helper functions
(currently ide and libata) fill in two new function pointers in the
queue structure. A sysfs 'protect' queue attribute is then created in
the block layer for devices who's lower level drivers have registered
these helpers.
When a value (in seconds) is written to the protect attribute, the block
layer code calls the driver 'protect' helper function. This helper
parks/suspends the disk, and then stops the queue. Control then returns
to the block layer which re-uses the plugging timer to set an automatic
timeout to restart the queue. When 0 is written to the protect
attribute, or the timer expires, the queue is restarted using the
'unprotect' helper function, and the plugging timer is restored.
This interface is intended to be used by a daemon process, that monitors
the hdaps driver output for excessive changes in acceleration, and keeps
the device parked and the queue stopped until the values become normal.
Patch applies to 2.6.14-rc3 (also 2.6.13.x), and requires libata_passthru..
Regards,
Jon.
______________________________________________________________
Email via Mailtraq4Free from Enstar (http://www.mailtraqdirect.co.uk)
On Fri, Oct 07 2005, Jon Escombe wrote:
> I would like to submit the latest disk protection (a.k.a. parking and
> freezing) code from the hdaps-devel side for comment, along with a brief
> overview of what's in the patch -
>
> During initialisation, disk drivers with 'protect' helper functions
> (currently ide and libata) fill in two new function pointers in the
> queue structure. A sysfs 'protect' queue attribute is then created in
> the block layer for devices who's lower level drivers have registered
> these helpers.
>
> When a value (in seconds) is written to the protect attribute, the block
> layer code calls the driver 'protect' helper function. This helper
> parks/suspends the disk, and then stops the queue. Control then returns
> to the block layer which re-uses the plugging timer to set an automatic
> timeout to restart the queue. When 0 is written to the protect
> attribute, or the timer expires, the queue is restarted using the
> 'unprotect' helper function, and the plugging timer is restored.
>
> This interface is intended to be used by a daemon process, that monitors
> the hdaps driver output for excessive changes in acceleration, and keeps
> the device parked and the queue stopped until the values become normal.
>
> Patch applies to 2.6.14-rc3 (also 2.6.13.x), and requires libata_passthru..
I have to nack this one for now, I still want the generic command types
patch to go in first. 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.
My suggestion is to maintain this patch out of tree for now, it will be
a few kernel release iterations before the command type patch is in.
--
Jens Axboe
Jens Axboe wrote:
>I have to nack this one for now, I still want the generic command types
>patch to go in first. 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.
>
>My suggestion is to maintain this patch out of tree for now, it will be
>a few kernel release iterations before the command type patch is in.
>
>
That's a fair comment (and not entirely unexpected), I don't have a
problem with looking after this out of tree for now...
One issue with the generic command approach occured to me while making
this patch - although it's more likely an issue with my understanding ;)
I'm assuming that it would work like this -- the block layer still has
the sysfs attribute, and queues the new command for the lower driver to
pick up. The driver receives the command and does it's custom
park/freeze work, then calls a common block layer function to setup the
timer (all good so far). Where it gets hazy (for me) is how the block
layer starts the queue up again - as this ended up needing to be driver
specific & I can't see how the block layer would get another command
down if the queue is stopped?
Regards,
Jon.
______________________________________________________________
Email via Mailtraq4Free from Enstar (http://www.mailtraqdirect.co.uk)
On Fri, Oct 07 2005, Jon Escombe wrote:
> Jens Axboe wrote:
>
> >I have to nack this one for now, I still want the generic command types
> >patch to go in first. 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.
> >
> >My suggestion is to maintain this patch out of tree for now, it will be
> >a few kernel release iterations before the command type patch is in.
> >
> >
>
> That's a fair comment (and not entirely unexpected), I don't have a
> problem with looking after this out of tree for now...
>
> One issue with the generic command approach occured to me while making
> this patch - although it's more likely an issue with my understanding ;)
>
> I'm assuming that it would work like this -- the block layer still has
> the sysfs attribute, and queues the new command for the lower driver to
> pick up. The driver receives the command and does it's custom
> park/freeze work, then calls a common block layer function to setup the
> timer (all good so far). Where it gets hazy (for me) is how the block
> layer starts the queue up again - as this ended up needing to be driver
> specific & I can't see how the block layer would get another command
> down if the queue is stopped?
It just sends an unfreeze request. It's similar to how we have to allow
suspend commands on an otherwise suspended queue. Since the block layer
has control of the frozen queue, it should not be a problem.
--
Jens Axboe