[dm-devel] [PATCH] dm-delay: Add a message to change delay

[Vivek Goyal]

On Mon, Aug 31, 2015 at 10:02:33PM -0700, Andy Grover wrote:
> On 08/31/2015 07:05 PM, Vivek Goyal wrote:
> >On Mon, Aug 31, 2015 at 02:24:36PM -0700, Andy Grover wrote:
> >>This enables runtime modification of the read and write delay values.
> >>
> >>Make sure if the delay time is reduced to flush currently-delayed
> >>bios first, to maintain ordering.
> >>
> >>Signed-off-by: Andy Grover <agrover at redhat.com>
> >>---
> >>  Documentation/device-mapper/delay.txt |  8 +++++++
> >>  drivers/md/dm-delay.c                 | 42 +++++++++++++++++++++++++++++++++++
> >>  2 files changed, 50 insertions(+)
> >>
> >>diff --git a/Documentation/device-mapper/delay.txt b/Documentation/device-mapper/delay.txt
> >>index 15adc55..9e80751 100644
> >>--- a/Documentation/device-mapper/delay.txt
> >>+++ b/Documentation/device-mapper/delay.txt
> >>@@ -10,6 +10,14 @@ Parameters:
> >>  With separate write parameters, the first set is only used for reads.
> >>  Delays are specified in milliseconds.
> >>
> >>+Message Interface
> >>+-----------------
> >>+The delay target will accept a message of the following format:
> >>+
> >>+set_delay <read_delay> [<write_delay>]
> >>+
> >
> >Hi Andy,
> >
> >So if I want to change only write_delay and keep read_delay same, how do
> >I do that. Do I have to keep track of existing delay values in user space
> >and pass same value in read_delay to achieve this.
> >
> >Thanks
> >Vivek
> 
> Hi Vivek,
> 
> Yes I suppose userspace would either need to remember read_delay so as to
> not change it while setting write_delay, or I guess it could read the
> existing values by getting table status before sending the message. Is this
> reasonable, or do you think it would be better to, say, have separate
> messages for setting the two values, or some other message style?

Ideally I think we should have those --key=value type of arguments which
we don't have yet. So that option is not feasible I guess.

If latest values are readable from status, then I think single message
sounds reasoanble to me.

Thanks
Vivek

> 
> Thanks -- Regards -- Andy