Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Lars Ellenberg <Lars.Ellenberg at ...> writes:
>
> / 2004-04-07 11:37:05 +1000
> \ Jeff Goris:
> > I actually had put this problem aside for over a week due to other more
> > urgent work. It was only when using rpm to install some security updates
> > that I became aware of the time zone problem on the dodgy host. I'm not
> > positive that I had changed nothing else on either host. It was immediately
> > after fixing the time that I tried a max sync rate of 50 M/sec and managed
> > to get it to sync fairly constantly at 22,500 K/sec.
>
> DRBD has no idea about wall clock time or timezone.
> So I can not think of how different wall clock time
> on the peers would influence DRBD behaviour in any way.
>
> Lars Ellenberg
>
Sorry about all my previous posts being in a new thread. Hopefully, this won't
happen again.
Okay, I have reproduced the problem. The crash was caused whilst NTP was
drifting the clock from the incorrect time to the correct time. The clock was
wrong because a) system clock used UTC, b) I had a timezone about 18 hours
behind what it should have been, c) I manually set the time on this host to
the current local time and the system clock would have then been 18 hours
ahead of the other host.
To reproduce the problem I simply used the date command on the secondary to
set the wall clock time 3 hours in advance of the primary and manually started
a full sync on the primary. Part way through the sync the secondary locks up
and the primary looks like this:
version: 0.6.12 (api:64/proto:62)
0: cs:WFConnection st:Primary/Unknown ns:267736652 nr:0 dw:144 dr:267736805
pe:0 ua:0
NEEDS_SYNC
Jeff.