Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Jul 31, 2012 at 01:06:30PM +0200, Sebastian Riemer wrote: > On 31.07.2012 12:14, David Coulson wrote: > > Does it matter? Your data is accessible from both nodes while it syncs. > > > > I suppose you have a risk of the primary failing until it has a full > > copy on the other node, but since it is a one time, on build, thing it > > isn't a big deal. > > > > Short answer is bigger pipe, faster drives, plenty of cpu. And more > > pipe. And make sure your configured syncer rate is enough to fully > > utilize your connectivity between nodes. > > To add one thing here: DRBD should stop using very slow 4 KiB IO > requests for syncer stuff. You can see that with blktrace/blkparse. > Full-size 512 KiB IO requests should be used instead. > Only fools add hardware to fix a software issue. > > I've analyzed the DRBD kernel code recently for a customer: > http://www.gossamer-threads.com/lists/drbd/users/24104 8.3.whatever used to do 32k requests, or sometimes even smaller, I don't quite remember. Current 8.3 does 128kB requests, 8.4 does 1MB requests (if the lower level can handle it). At least for me. > Btw.: The default syncer rate limit of 10 MB/s is also quite outdated. That has never been the default. 250 kByte/s was the default for the sync rate, and that was to have minmal impact on application IO by default. Today, you should use the dynamically adapdive resync rate controller to achive that same thing (minimal impact on application IO during resync). That's the settings c-plan-ahead, c-min-rate, c-max-rate, c-fill-target. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com