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

[Kevin Wolf <kwolf@redhat.com>]

Am 21.06.2010 18:21, schrieb Markus Armbruster:
> Christoph Hellwig <hch@lst.de> writes:
> 
>> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
>>> I can appreciate the desire to keep protocols and formats as an internal 
>>> distinction but as a user visible concept, I think your two examples 
>>> highlight why exposing protocols as formats make sense.  A user doesn't 
>>> necessarily care what's happening under the cover.  I think:
>>>
>>> -blockdev format=qcow2,file=image.qcow2,id=blk1
>>>
>>> and:
>>>
>>> -blockdev protocol=vvfat,file=/tmp/dir,id=blk1
>>>
>>> Would cause a bit of confusion.  It's not immediately clear why vvfat is 
>>> a protocol and qcow2 isn't.  It's really an implementation detail that 
>>> we implement qcow2 on top of a "protocol" called file.
>>
>> Everything involving vvfat will end up in sheer confusion, and that's
>> because vvfat is such a beast.
> 
> Yes, vvfat doesn't fit the format/protocol model very well, but that's
> because that model sucks :)

What's the different between vvfat and accessing a FAT image via nbd
(except that vvfat is broken)? It's clearly a protocol/transport, as
Christoph already said.

> vvfat is a block driver.  A block driver requires a number of children.
> For vvfat that number is zero.  It can only be a leaf in the block
> driver tree.
> 
> As with any block driver, you can stack another block driver on top of
> it (the parent, in tree parlance).  Also as with any block driver, the
> parent might not like the bits it gets from the child.  Yes, stacking
> qcow2 on vvfat doesn't work.  Just like stacking qcow2 on your old DOS
> partition.
> 
>>                                 But it's a rather traditional example
>> of a "protocol".  Unlike qcow2 / vmdk / vpc it can not be stacked on
>> an arbitrary protocol (file/nbd/http), but rather accessed a directory
>> tree.  vvfat then makes up something that looks like a file so upper
>> levels can use it like that.  As far as qemu is concerned you can then
>> use any format on top of it, but given that it fakes up a fat filesystem
>> that format better be raw to make sense.
>>
>> What about renaming the protocol a transport?  It seems like a lot
>> of issues here seem to resolve around naming.
>>
>> The user basically can specify two things:
>>
>>  - a transport protocol.  Normally this is just the filesystem
>>    interface, but it can also be nbd, http or for really sick people
>>    vvfat.  This is a setting which can't be guessed, btw - it needs
>>    to be explicitly set in some way, with file used as a reasonable
>>    fallback.
>>
>>  - an image format.  This one interprets the content the transport
>>    protocol delivers to us.  This can either be raw for not interpreting
>>    it all, or things like qcow2 / vmdk to add more functionality to it.
> 
> 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.

No, that's not a special case. It's the only case there is.

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

Sure you can stack formats on it. raw and blkdebug are the ones that
will be happy with the data that vvfat provides.

Kevin