On Fri, Dec 23, 2016 at 05:28:43PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> This is a new architecture for backup. It solves some current problems:
> 1. intersecting requests: for now at request start we wait for all
> intersecting requests, which means that
> a. we may wait even for unrel
On 01/10/2017 01:05 AM, Jeff Cody wrote:
> On Mon, Jan 09, 2017 at 11:04:27AM +, Stefan Hajnoczi wrote:
>> On Fri, Dec 23, 2016 at 05:28:43PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>>
>> Jeff or John: are you reviewing this?
>
> It's in my review queue, but it would probably be a good on
On Mon, Jan 09, 2017 at 11:04:27AM +, Stefan Hajnoczi wrote:
> On Fri, Dec 23, 2016 at 05:28:43PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>
> Jeff or John: are you reviewing this?
It's in my review queue, but it would probably be a good one for John to
review as well if he has time.
>
>
On Fri, Dec 23, 2016 at 05:28:43PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Jeff or John: are you reviewing this?
> This is a new architecture for backup. It solves some current problems:
> 1. intersecting requests: for now at request start we wait for all
> intersecting requests, which means
Hi all.
This is a new architecture for backup. It solves some current problems:
1. intersecting requests: for now at request start we wait for all intersecting
requests, which means that
a. we may wait even for unrelated to our request clusters
b. not full async: if we are going to copy c