[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: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v2 2/3] block/fleecing-filter: new filter driver for fleecing
Date: Mon, 2 Jul 2018 14:35:15 +0800
User-agent: Mutt/1.10.0 (2018-05-17)

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)?

> 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.


reply via email to

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