|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: [Qemu-block] [PATCH v2 2/3] block/fleecing-filter: new filter driver for fleecing |
Date: | Mon, 2 Jul 2018 14:27:01 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
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 readingclient starts reading2. 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 file4. 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 imageInteresting 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
[Prev in Thread] | Current Thread | [Next in Thread] |