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-08 01:58:22 +0000 \ Jeff Goris: > 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 > and DRBD is the "only" thing running here, and if the nodes do not differ in time all works smoothly. is this what you are saying? lge