Re: [Qemu-devel] [PATCH] block: Make op blocker recursive

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On 06/19/2014 11:01 PM, Fam Zheng wrote:
> On Thu, 06/19 22:20, Benoît Canet wrote:
>> The Thursday 19 Jun 2014 à 14:13:20 (-0600), Eric Blake wrote :
>>> On 06/19/2014 02:01 PM, Benoît Canet wrote:
>>>> As the code will start to operate on arbitratry nodes we need the op blocker
>>>
>>> s/arbitratry/arbitrary/
>>>
>>>> to recursively block or unblock whole BDS subtrees.
> 
> I don't get the reason, can you elaborate?

Consider what happens if I have:

base <- snap1 <- active

then I start a fleecing NBD server on the state as it was at snap1:

base <- snap1 <- active
              \- fleecing

then I do a blockpull into active:

base <- snap1 <- fleecing
active

at this point, base and snap1 are no longer tied to active, but they
STILL must be protected from operations that would modify their contents
in a way that would break the fleecing operation.  The solution we are
looking at is making BDS blockers recursive to every element of the
chain, not just the top-level device.

Another example: consider:

base <- snap1 <- active

then someone uses Jeff's proposed new change-backing-file QMP command to
rewrite the snap1 metadata to point to base via a relative name instead
of an absolute name.  It shouldn't matter whether active is blocked, but
only whether snap1 is blocked.  But to know if snap1 is blocked, we have
to propagate the blockers of active down recursively to its backing files.

>> What would be a cleaner solution ?
> 
> What is the question to solve?

I think Jeff's idea is on target - rather than blocking by operation, we
should instead be blocking on access patterns (various operations
trigger several access patterns):
https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg04752.html

Jeff's initial list included:

> So if I think of operations that are done on block devices from a
> block job, and chuck them into categories, I think we have:
> 
> 1) Read of guest-visible data
> 2) Write of guest-visible data
> 3) Read of host-visible data (e.g. image file metadata)
> 4) Write of host-visible data (e.g. image file metadata, such as
> the backing-file)
> 5) Block chain manipulations (e.g. movement of a BDS, change to r/w
> instead of r/o, etc..)
> 6) I/O attribute changes (e.g. throttling, etc..)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]