Re: [Qemu-devel] [PATCH] Add tar container format

[Christoph Hellwig]

On Thu, Aug 13, 2009 at 06:13:27PM -0500, Anthony Liguori wrote:
> What's attractive about doing plugins for the block layer is that we 
> have a relatively stable interface for block drivers.  The current AIO 
> ops should be good for a very long time so API churn shouldn't be a 
> major issue.  The code is all pretty well isolated today.
> 
> As part of the longer term refactoring, I think it also makes sense to 
> split the block layer into a library that can be consumed independent of 
> QEMU.  Obviously, folks want to make use of our block code who don't 
> care at all about QEMU.  A lot of people use qemu-img for vmdk 
> manipulation, for instance.  It also makes tools like qemu-iotest able 
> to consume the block layer in a saner way.
> 
> If others agree, I think we should start going down this road.  
> block-tar/block-dictzip seem like obvious candidates for plugins.

Splitting drivers from the core is a total desaster, you'll end up with
the same crap as the X drivers vs core X server versioning mess.  After
a long stabilization period we might be able to split the block layer
_including_ the drivers from qemu if we really want.  Splitting the
drivers into tiny subpackages would be plain stupid.

As far as additional image formats are concerned I'm personally not a
fan at all of any of that image format crap we have right now.  Anything
like qcow and friends or other formats that do complex metadata
manipulation in userspace is a really bad idea for data integrity.
Supporting simple containers with static metadata is absolutely fine,
even more so it it's read-only like the tar container here.

But one problem with tar is that there are many slightly or even totally
different tar formats and extensions around.  It's not nessecarily a
format I would personally chose for a product.  That's something the
SuSE stuio people should think about, but nothing that should prevent
us from including the format.