29.06.2018 20:40, Eric Blake wrote:
On 06/29/2018 12:30 PM, John Snow wrote:
On 06/29/2018 11: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:
1. client start reading
2. client understand, that there is no corresponding cluster in
fleecing image
I don't think the client refocuses the read, but QEMU does. (the client
has no idea if it is reading from the fleecing node or the backing
file.)
... but understood:
3. client is going to read from backing file (i.e. active image)
4. guest writes to active image
My question here is if QEMU will allow reads and writes to interleave in
general. If the client is reading from the backing file, the active
image, will QEMU allow a write to modify that data before we're done
getting that data?
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
I can't answer this for myself one way or the other right now, but I
imagine you observed a failure in practice in your test setups, which
motivated this patch?
A test or some proof would help justification for this patch. It would
also help prove that it solves what it claims to!
In fact, do we really need a new filter, or do we just need to make
the "sync":"none" blockdev-backup job take the appropriate
synchronization locks?
How? We'll need additional mechanism like serializing requests.. Or a
way to reuse serializing requests. Using backup internal synchronization
looks simpler, and it is already used in block replication.
On the other hand, I think the best thing is instead refuse
backup(sync=none), and do the whole functionality for external backup in
the special filter driver, but for now I'd prefer to start with already
existing staff.
--
Best regards,
Vladimir
