Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 :) Otherwise I will have to suspend the writing application until the disk image has been completely created. 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? K. Haselhorst