[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v2 2/3] block/fleecing-filter: new filter driver for fleecing
Date: Mon, 2 Jul 2018 15:09:45 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]