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, May 11, 2010 at 08:27:24AM +0200, Katharina Haselhorst wrote: > Hello, > > On 05/10/2010 08:37 PM, 'Lars Ellenberg' wrote: > >On Mon, May 10, 2010 at 01:56:30PM -0400, Dan Barker wrote: > >>> > >>>Starting with old uuid, possibly partially dirty bitmap. > >>> > >>>[A] Generate new uuid, clean bitmap. > >>> The now clean bitmap will be re-dirtied with > >>> everything that is written from now on. > >>>[B] Disk gets pulled, imaged, whatever. > >>>[C] Second new uuid generated. > >>> (*NOT* clearing the bitmap this time) > >>> This marks the end of the imaging/disk pulling. > >>> Bitmap contains everything that has been redirtied since [A] > >>>[D] bitmap continues to be updated. > >>>[E] Connect of image (from [B]) to current: > >>> normal bitmap based resync. > >>> Everything that has been re-dirtied since [A] will be resynced. > >>> > >>>Or do I have to suspend Host A (at least the > >>>application writing to that device) for that time? > >>> > >>>No. > >>>If you can minimize write activity between [A] and [E], > >>>you will have a minimal resync. > >> > >> > >>Lars: > >> > >>I read her question as "Must I suspend between [A] and [C]". I would think > >>it would depend on the imaging process utilized. > > My question rather concerned the time between [A] and the > termination of [B]. Since the imaging process takes some time, (I do > not pull out some physical hard disk, but create a disk image > archive) there will always be a gap between 1. the generation of the > first bitmap in [A] and the start of [B] and 2. between the start > and the termination of [B]. So the synchronization algorithm will > have to deal with the fact, that the data+metadata archived does not > correspond to the state where the first bitmap gets taken and > potentially that even the data and the metadata are out of sync > (since they both get written to during the archivation). If this > does not pose any problems - fine :) It does not. I'll not explain it a third time, though. If my explanation is in any way unclear, please point that out, and I'll try to clarify. > Another question: in the config file it is possible to adjust the > send rate for the background synchronization. Is there a option for > saying "as fast as possible"? Since the transmission is done via > tcp, the sending rate will adopt automatically to the capacity of > the link and the writing speed of the destination. I know, that this > will possibly degrade network performance of other applications > using the same link, but at the time of the first background > synchronization primary goal is to get the task done as fast as > possible. Is it wise to simply set an unrealistically high value for > the sending rate to get maximum performance of the synchronization? Using a rate "a bit" over the physical link bandwidth is ok. Using a rate "much" higher than the physical link bandwidth won't help, and may or may not hurt total throughput. You may set an "unrealistically high value", but any application IO on the disk will suffer huge latencies during resync. You can simply try, and reduce syncer rate again if the performance hit is too hard. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed