[Qemu-devel] Re: KVM call agenda for Apr 27

[Avi Kivity]

On 04/27/2010 04:03 PM, Anthony Liguori wrote:
> On 04/27/2010 03:14 AM, Avi Kivity wrote:
> > On 04/27/2010 01:36 AM, Anthony Liguori wrote:
> > > A few comments:
> > >
> > > 1) The problem was not block watermark itself but generating a 
> > > notification on the watermark threshold.  It's a heuristic and 
> > > should be implemented based on polling block stats. 
> >
> > Polling for an event that never happens is bad engineering.  What 
> > frequency do you poll?  you're forcing the user to make a lose-lose 
> > tradeoff.
> >
> > > Otherwise, we'll be adding tons of events to qemu that we'll 
> > > struggle to maintain.
> >
> > That's not a valid reason to reject a user requirement.  We may argue 
> > the requirement is bogus, or that the suggested implementation is 
> > wrong and point in a different direction, but saying that we may have 
> > to add more code in the future due to other requirements is ... well 
> > I can't find a word for it.
>
> Polling is the best solution because it offers the most flexibility.  
> Baking the heuristic into qemu just removes flexibility for all 
> consumers.

Can you explain?  The ability to poll is not removed.  Nor is any 
heuristics performed by qemu; it just sends a notification when a write 
exceeds a user-defined threshold.  The distance from the threshold to 
the top-of-file is not known to qemu.

> > > 2) A block plugin doesn't solve the problem if it's just at the 
> > > BlockDriverState level because it can't interact with qcow2.
> >
> > Why not?  We have a layered model.  guest -> qcow2 -> plugin (sends 
> > event) -> raw-posix.  Just need to insert the plugin at the 
> > appropriate layer.
>
> All of the qcow2 information is static to the qcow2 driver and I don't 
> think changing that for plugins is a good idea.

There is no information that the plugin needs to access:

  if (write_offset > watermark && watermark_enabled) {
      send_notification();
      watermark_enabled = false;
  }
  bdrv_write(backing_blockstate, ..., write_offset, ...);

Note write_offset if not the guest's offset, but the offset into the 
backing file.  It will trigger on guest writes and qcow2 metadata writes 
alike.

> > > 3) For general block plugins, it's probably better to tackle 
> > > userspace block devices.  We have CUSE and FUSE already, a BUSE is a 
> > > logical conclusion.
> >
> > We also have an nbd client.
> >
> > Here's another option:  an nbd-like protocol that remotes all 
> > BlockDriver operations except read and write over a unix domain 
> > socket.  The open operation returns an fd (SCM_RIGHTS strikes again) 
> > that is used for read and write.  This can be used to implement 
> > snapshots over LVM, for example.
>
> How does it address the watermark problem?

It doesn't. Mea confusa.

--
error compiling committee.c: too many arguments to function