Am 08.02.2012 07:10, schrieb Ori Mamluk: > On 07/02/2012 17:47, Paolo Bonzini wrote: >> On 02/07/2012 03:48 PM, Ori Mamluk wrote: >>>> The current streaming code in QEMU only deals with the former. >>>> Streaming to a remote server would not be supported. >>>> >>> I need it at the same time. The Rephub reads either the full volume or >>> parts of, and concurrently protects new IOs. >> >> Why can't QEMU itself stream the full volume in the background, and >> send that together with any new I/O? Is it because the rephub knows >> which parts are out-of-date and need recovery? In that case, as a >> first approximation the rephub can pass the sector at which streaming >> should start. > Yes - it's because rephub knows. The parts that need recovery may be a > series of random IOs that were lost because of a network outage > somewhere along the replication pipe. > Easy to think of it as a bitmap holding the not-yet-replicated IOs. The > rephub occasionally reads those areas to 'sync' them, so in effect the > rephub needs read access - it's not really to trigger streaming from an > offset.
So how does the rephub know which areas were touched by lost requests? Isn't qemu the only one who could know what it sent? Kevin
