Re: [Qemu-devel] [PATCH] Revert block-qcow2.c to kvm-72 version due to corruption reports

[Anthony Liguori]

Johannes Schindelin wrote:
> Hi,
>
> On Sun, 15 Feb 2009, Anthony Liguori wrote:
>
>   
> > And let's be clear, your data is *not* safe with qcow2.  So I don't 
> > consider this to be a show stopping issue.
> >     
>
> I beg your pardon?  The one format that was recommended for quite a long 
> time now is considered unsafe?
>   

Let me be abundantly clear here.  qcow2 has never been the "recommended" 
format IMHO.  When it was introduced, it was introduced as 
experimental.  This is why block-qcow2.c was forked instead of qcow2 
support being integrated into block-qcow.c.  There's a ton of duplicate 
code between the two.  The plan was to eventually merge the two once 
qcow2 stabilized.  That's not happened.  The code was never improved 
much since it's introduction until recently.

I have concerns about the fundamental design of qcow2.  I believe it 
will be difficult to make it safe while having acceptable performance.  
There has been some work recently by Gleb Natapov to reduce the 
corruption window in qcow2 but it's still there.

I can only recommend qcow2 to casual users.  It should *not* be used in 
production environments.  It pains me to say that because we don't have 
a good alternative but there's no way I could recommend its use.

In particular, Jamie's patch reverts one set of patches that reduces the 
corruption window to "fix" a corruption bug that is now being 
experience.  However, since we don't know exactly what the cause of the 
new bug is, it's not necessarily true that the revert fixes the bug.  It 
may just make it more difficult to expose.

There's really no winning scenario here except finding the root cause of 
the new bug and fixing it.  That still won't make qcow2 safe for 
production data though.  So as far as I'm concerned, until qcow2 is made 
completely safe, it's still an experimental feature.

Regards,

Anthony Liguori

> That would not have happened with Fabrice in charge,
> Dscho
>
>