[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] How to introduce bs->node_name ?
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] How to introduce bs->node_name ? |
Date: |
Mon, 4 Nov 2013 12:06:14 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 04.11.2013 um 10:48 hat Fam Zheng geschrieben:
>
> On 11/04/2013 05:31 PM, Stefan Hajnoczi wrote:
> >On Wed, Oct 30, 2013 at 02:49:32PM +0100, Markus Armbruster wrote:
> >>The first proposal is to add another parameter, say "id". Users can
> >>then refer either to an arbitrary BDS by "id", or (for backward
> >>compatibility) to the root BDS by "device". When the code sees
> >>"device", it'll look up the BB, then fetch its root BDS.
> >>
> >>CON: Existing parameter "device" becomes compatibility cruft.
> >>
> >>PRO: Clean and obvious semantics (in my opinion).
> >This proposal gets my vote.
> >
> >>The second proposal is to press the existing parameter "device" into
> >>service for referring to BDS node_name.
> >>
> >>To keep backward compatibility, we obviously need to ensure that
> >>whenever the old code accepts a value of "device", the new code accepts
> >>it as well, and both resolve it to the same BDS.
> >Different legacy commands given the same device name might need to
> >operate on different nodes.
> Could you give an example for this?
>
>
> >Dynamic renaming does not solve this
> >problem, so I'm not convinced we can always choose a device name
> >matching a node name.
> >
> >Device name commands are higher-level than graph node commands. For
> >example, block_set_io_throttle makes sense on a device but less sense on
> >a graph node, unless we add the implicit assumption that the new
> >throttling node is created on top of the given node or updated in place
> >if the throttling node already exists (!!).
> Throttling a node could be useful too, for example if we want to
> throttle backing_hd which is on shared storage, but not to throttle
> on the local image.
>
> My ignorant question is: Why can't we just use one namespace, make
> sure no name collision between node_name and device_name, or even
> just drop device_name, so we treat the root node's node_name as
> device_name? For commands that only accept a device, this can be
> enforced in its implementation by checking against the whole graph
> to verify this.
Markus described it somewhere in this thread: Live snapshots.
Currently, the device_name moves to the new BDS on the top (and
compatibility requires us to keep it that way), whereas a node name
should, of course, stay at its node.
When you consider this, the single namespace, as much as I would have
loved it, is pretty much dead.
Kevin