[DRBD-user] Initial Sync - Fast then really slow

Lars Ellenberg Lars.Ellenberg at linbit.com
Mon Apr 12 19:52:59 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


/ 2004-04-12 12:15:19 -0500
\ Todd Denniston:
> > The only thing where DRBD has a notion of time are some local
> > timers, connection timeout and so on. It just deferres certain
> > actions by some configured amount of time (usual seconds)
> > relative to "now". E.g. I issue a DrbdPing, and then set a
> > timer to notify me after, say, 6 seconds... if the peer
> > answers in time, the timer action is discarded again.
> > 
> > A smoothly adjusting time via NTPD by sub-second amounts...
> > How should that be noticed at all, and by whom?  Not by DRBD.
> > 
> <SNIP> Note, unless '-x' is passed to NTPD, with an offset of 8
> hours ntp will "jump" the time about 8 to 10 minutes[1] in after
> it detects the large offset, it will also do this anytime there
> is more than 128ms offset.  '-x' 'forces the time to be slewed
> in all cases.'[2]
> 
> 
> So Lars, should we expect bad things to happen if the jump is
> over 6 seconds in one direction or another?

No. As I said, this *should* go unnoticed.
After smoking some psychedelic stuff, I might be able to imagine a race
condition which could lead to connection loss and immediate reconnect
under very weird circumstaces...  I'd of course deny that when sober ...

> [Jump forward should expire the timer early in wall time] [Jump
> back should expire the timer 'jump time delta' later in wall
> time] I have seen X (or rather X apps) do funny things when you
> set the system time backward while it is running, like not
> updating screens.

Hm. Under very weird circumstances, it might take longer to recognize a
broken link or crashed peer. But not more than an other iteration of the
"hey, peer, do you copy? /yes, peer here, whats up?/ ..." game...
which happens with an offset to "now" after every successfull
transmitted/received packet, unless some other packet is tx/rx earlier,
in which case the game it defered further. but always relative to "now"...

But, ok, many if not all timers used by the kernel may under certain
conditions behave "strange" when the time is not monotonously increasing,
including the network internal timers, and maybe even some hardware
related stuff...

	Lars Ellenberg



More information about the drbd-user mailing list