[DRBD-user] Initial Sync - Fast then really slow
Todd.Denniston at ssa.crane.navy.mil
Mon Apr 12 19:15:19 CEST 2004
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
> 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.
Note, unless '-x' is passed to NTPD, with an offset of 8 hours ntp will "jump"
the time about 8 to 10 minutes 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.'
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.
 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.
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
More information about the drbd-user