Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack

[Christoph Hellwig]

On Mon, Jun 21, 2010 at 06:21:09PM +0200, Markus Armbruster wrote:
> You describe the special case where format and protocol make some sense:
> you have a block driver that can transport bits in arbitrary formats,
> and a block driver that interprets bits without caring for transport.
> 
> In the general case, we have things like vvfat that make people wonder
> whether it's a format or a protocol.  You can't stack it onto a
> transport, so it can't be a format!  You can't stack a format on it, so
> it can't be a protocol!

Instead of starting to get hung up on the protocol name let's go back to
the basic problem.  We have two types of Block drivers in qemu, which
are fundamentally different:

 - leaf drivers which use some sort of native I/O method and present
   an image.  The typical cases for this are file/host_device/nbd/http/
   ceph/sheepdog which just transport arbitrary content over some transport.
   Another category makes up the content of the image on the fly.  This
   is generally an extreme hack as it's very hard to keep any kind of
   coherency if the underlying content changes, but we've unfortunately
   enough done it anyway for vvfat.  I don't think I would accept any
   addition driver of this type.
 - non-leaf drivers which stack on top of another qemu block driver.

I think the difference is important enough for a user to care.  It's
basically two different questions for the users:

 - what image format do I want
 - and where do I store that image

Even vvfat kinda fits into that model.  The users wants to store the
image as a "life" view of a directory hierachy on the host.  Because
of the limitation of that model the choice of image format ontop of
that storage solution is limited to raw.