Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, 25 Nov 2004, Per Liden wrote: [...] > I'm having problems with DRBD getting stuck at around 99-100% during an > initial/full sync. This seems to be happening about 8 out of 10 times. After some further testing it seems that I managed to resolve the issue. Changes I made to my configuration: - Removed LVM (DRBD now runs directly on top of my hda10 device). - Changed meta-data to "internal" (instead of hda9 [0]). - Filesystem used on top of /dev/drbd0 is now reiserfs instead of ext3. (I thought I should mention is, even if the choice of filesystem shouldn't have anything to do with my sync problem). So far I've done three full syncs without getting stuck. Unfortunately I did all the above changes in one go, so I can't really say if it was LVM or the separate meta-data partition that casued the problem. My guess is LVM though. Whether I can live without LVM is something I'll have to look into... [...] > Interesting to note is that the nodes seem to have different ideas about > how much data needs to be synchronized, i.e.: > Nov 25 11:07:03 Proc1 kernel: drbd0: Resync started as SyncSource (need to sync 60812372 KB [15203093 bits set]). > vs. > Nov 25 11:07:04 Proc2 kernel: drbd0: Resync started as SyncTarget (need to sync 60558500 KB [15139625 bits set]). After my reconfiguration I haven't seen any thing like this again. Every time a sync is initiated both nodes have a common understanding of the number of bytes that need to be synchronized. I also noticed that the average sync rate was much higher and more stable after my changes. Before the sync fluctuate between 1,000 and 25,000 Kb/s with an average of ~10,000 Kb/s. With my changes the sync rate was fairly stable with an average of ~20,000 Kb/s (sync rate was set to 30M in both configuration). /Per