[Drbd-dev] drbd-dev Digest, Vol 133, Issue 7
박경민
kmpak at mantech.co.kr
Mon Mar 14 06:37:21 CET 2016
I have known more request_timer_fn(). Thanks
I think helper function *time_min_in_future() *function will return the
nearest future time, right?
And, next_trigger_time is initialize now value, so always is same.
void request_timer_fn(unsigned long data)
{
if (dt) {
...
if (device->disk_state[NOW] > D_FAILED) {
next_trigger_time = *time_min_in_future*(now,
next_trigger_time, oldest_submit_jif + dt); //
1st assign
restart_timer = true;
}
...
}
for_each_connection(connection, device->resource) {
...
next_trigger_time = *time_min_in_future*(now,
next_trigger_time, pre_send_jif + ent); //
2nd assign
...
}
...
if (restart_timer) {
next_trigger_time = *time_min_in_future*(now, next_trigger_time,
now + et); // 3rd assign
...
}
}
Maybe, 3 assignments are always same, because now == next_trigger_time,
which is the nearest.
So, if restart_timer 's value is true, then loop continuously even dt or
ent exists.
I don't know how to put the different thing.
Thanks.
2016-03-11 20:00 GMT+09:00 <drbd-dev-request at lists.linbit.com>:
> Send drbd-dev mailing list submissions to
> drbd-dev at lists.linbit.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linbit.com/mailman/listinfo/drbd-dev
> or, via email, send a message with subject or body 'help' to
> drbd-dev-request at lists.linbit.com
>
> You can reach the person managing the list at
> drbd-dev-owner at lists.linbit.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of drbd-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: request_timer continuous loop if there is disk-timeout
> (Lars Ellenberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 11 Mar 2016 11:02:35 +0100
> From: Lars Ellenberg <lars.ellenberg at linbit.com>
> Subject: Re: [Drbd-dev] request_timer continuous loop if there is
> disk-timeout
> To: drbd-dev at lists.linbit.com
> Message-ID: <20160311100235.GD17669 at soda.linbit>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Mar 11, 2016 at 04:30:27PM +0900, ??? wrote:
> > Hello.
> > I'm a software engineer in Mantech.
> >
> > In testing about disk-timeout property,
> > if not default value, which will lead into a continuous loop.
> >
> > in request_timer_fn()
> > ...
> > if (device->disk_state[NOW] > D_FAILED) {
> > et = min_not_zero(et, dt);
> > next_trigger_time = time_min_in_future(now,
> > next_trigger_time, oldest_submit_jif + dt);
> > restart_timer = true;
> > }
> > ...
> > I think, if there is no request, next_trigger_time should be calculated
> > below
> > next_trigger_time = time_min_in_future(now,
> > next_trigger_time + *dt*, oldest_submit_jif + dt);
> >
> > However, I can't be sure.
>
> "dt" : disk timeout
> "et" : effective timeout
> "ent" : effective network timeout
> "now" : well, now.
> "next_trigger_time" : when to trigger the next timer
>
> next_trigger_time is initialized to "now".
>
> it gets adjusted using "time_min_in_future()",
> which is this helper:
> static unsigned long time_min_in_future(unsigned long now,
> unsigned long t1, unsigned long t2)
> {
> t1 = time_after(now, t1) ? now : t1;
> t2 = time_after(now, t2) ? now : t2;
> return time_after(t1, t2) ? t2 : t1;
> }
>
> time_after is ((long)((b) - (a)) < 0)), NOT <=.
>
> next_trigger_time will become larger than now,
> or stay at its initial value, which is now.
>
> function ends with
>
> if (restart_timer) {
> next_trigger_time = time_min_in_future(now,
> next_trigger_time, now + et);
> mod_timer(&device->request_timer, next_trigger_time);
> }
>
> so in case next_trigger_time will still be equal to now at the end of the
> function, it will be set to "now + et" before it is passed to mod_timer.
>
> et can only be zero if both network and disk timeout where zero,
> in which case the whole thing would not even be used,
> because that would mean timeouts are disabled.
>
>
> Besides that,
> I would be surprised if disk timeout in 9 worked properly yet.
>
> Also, disk timeout is evil in any case, and NOT TO BE USED
> (not even in 8.4, where it *does* work properly ("as designed"), afaik)
>
> Why? Because if it triggers, and the IO subsystem ("disk") decides to
> still process the submitted request some time later,
> you'd get stuff RDMA'd to some random memory page which may well be
> meanwhile
> re-used for unrelated things. In which case we intentionally panic().
>
> But you knew that already.
>
> --
> : Lars Ellenberg
> : LINBIT | Keeping the Digital World Running
> : DRBD -- Heartbeat -- Corosync -- Pacemaker
> : R&D, Integration, Ops, Consulting, Support
>
> DRBD? and LINBIT? are registered trademarks of LINBIT
>
>
> ------------------------------
>
> _______________________________________________
> drbd-dev mailing list
> drbd-dev at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-dev
>
>
> End of drbd-dev Digest, Vol 133, Issue 7
> ****************************************
>
--
기술연구소 Mobile : 010-4762-0519
*박 경 민 차장* kmpak at mantech.co.kr
서울특별시 성동구 성수일로4길 25 서울숲코오롱디지털타워 12층
Fax : 02-575-4858 / Tel : (02) 2136-6978 (978)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-dev/attachments/20160314/d3998edd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4544 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-dev/attachments/20160314/d3998edd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 16223 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-dev/attachments/20160314/d3998edd/attachment-0003.png>
More information about the drbd-dev
mailing list