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

[Mike Snitzer]

On Tue, Sep 01 2015 at  8:14am -0400,
Vivek Goyal <vgoyal at redhat.com> wrote:

> 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.

As Zdenek already effectively said: there is no need for this patch.
You don't need to use a message when a table reload would suffice to
change the parameter that is already passed on the table ctr.

Any layer that would be trained to send a message can just as easily be
trained to reload the table to achieve the same result.