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 wrote: > > / 2004-04-11 15:38:05 +0000 > \ Jeff Goris: > > > > That is correct. The machine is only doing DRBD - both > > > > machines are freshly installed with just DRBD and heartbeat > > > > setup. The problem occurs whether or not /dev/nb0 is mounted > > > > or unmounted. The only resources Heartbeat manages in the > > > > cluster is one DRBD device and one virtual IP address. > > > > > > please reproduce it without heartbeat... "by hand" > > > Thanks. > > > > > > > I managed to reproduce it again. /dev/nb0 was unmounted and heartbeat and DRBD > > were stopped on both hosts. Then checked that all RAID devices were healthy > > and that the time on both hosts were correct and synchronised. Started DRBD > > (command 'service drbd start') on the host that was last primary. Started drbd > > on the secondary and monitored the hosts durng the syncall of /dev/nb0. When > > finished, I set the clock on the secondary forward 8 hours with the 'date' > > command. Finally, I started a resync on the primary with the <SNIP> > Ok. > > 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? [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. [1] the 8 to 12 minutes is from personal experimentation, during the time when the machines are checking time every 64 seconds. If ntpd is synching 1024 seconds and you only have one host, it may take more like 30 minutes to 1 hour before it does the jump. [2] http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter