On Tue, Sep 01 2015 at 8:14am -0400, Vivek Goyal <vgoyal@xxxxxxxxxx> 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@xxxxxxxxxx> > > >>--- > > >> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
