[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack |
Date: |
Tue, 22 Jun 2010 10:32:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 |
Am 21.06.2010 18:21, schrieb Markus Armbruster:
> Christoph Hellwig <address@hidden> 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
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, (continued)
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Kevin Wolf, 2010/06/21
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/21
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Christoph Hellwig, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Paul Brook, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Christoph Hellwig, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Markus Armbruster, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Markus Armbruster, 2010/06/21
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack,
Kevin Wolf <=
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Markus Armbruster, 2010/06/22
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Christoph Hellwig, 2010/06/28
- Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack, Jamie Lokier, 2010/06/22
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/21
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Kevin Wolf, 2010/06/22
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/22
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Kevin Wolf, 2010/06/22
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Anthony Liguori, 2010/06/22
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Markus Armbruster, 2010/06/21
- [Qemu-devel] Re: block: format vs. protocol, and how they stack, Kevin Wolf, 2010/06/22