Re: [Qemu-devel] [PATCH v2 2/3] block/fleecing-filter: new filter driver for fleecing

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

02.07.2018 09:35, Fam Zheng wrote:
> On Fri, 06/29 12:24, Eric Blake wrote:
>> On 06/29/2018 10:15 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> We need to synchronize backup job with reading from fleecing image
>>> like it was done in block/replication.c.
>>>
>>> Otherwise, the following situation is theoretically possible:
>>>
>> Grammar suggestions:
>>
>>> 1. client start reading
>> client starts reading
>>
>>> 2. client understand, that there is no corresponding cluster in
>>>      fleecing image
>>> 3. client is going to read from backing file (i.e. active image)
>> client sees that no corresponding cluster has been allocated in the fleecing
>> image, so the request is forwarded to the backing file
>>
>>> 4. guest writes to active image
>>> 5. this write is stopped by backup(sync=none) and cluster is copied to
>>>      fleecing image
>>> 6. guest write continues...
>>> 7. and client reads _new_ (or partly new) date from active image
>> Interesting race. Can it actually happen, or does our read code already
>> serialize writes to the same area while a read is underway?
> Yes, I wonder why wait_serialising_requests() is not enough. If it's possible,
> can we have a test case (with help of blkdebug, for example)?

Hmm, only unaligned and COPY_ON_READ requests are marked serializing.. 
So If I understand correctly, nothing special prevents intersection, 
it's a problem of the guest. But in backup case, it's our problem.

>
>> In short, I see what problem you are claiming exists: the moment the client
>> starts reading from the backing file, that portion of the backing file must
>> remain unchanged until after the client is done reading.  But I don't know
>> enough details of the block layer to know if this is actually a problem, or
>> if adding the new filter is just overhead.
> Fam


-- 
Best regards,
Vladimir