Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori]

On 09/09/2010 01:45 AM, Avi Kivity wrote:
> Loading very large L2 tables on demand will result in very long 
> latencies.  Increasing cluster size will result in very long first 
> write latencies.  Adding an extra level results in an extra random 
> write every 4TB.

It would be trivially easy to add another level of tables as a feature 
bit so let's delay the decision.

> > qed is very careful about ensuring that we don't need to do syncs and 
> > we don't get corruption because of data loss.  I don't necessarily 
> > buy your checksumming argument.
>
> The requirement for checksumming comes from a different place.  For 
> decades we've enjoyed very low undetected bit error rates.  However 
> the actual amount of data is increasing to the point that it makes an 
> undetectable bit error likely, just by throwing a huge amount of bits 
> at storage.  Write ordering doesn't address this issue.

I don't think we should optimize an image format for cheap disks and an 
old file system.

We should optimize for the future.  That means a btrfs file system 
and/or enterprise storage.

The point of an image format is not to recreate btrfs in software.  It's 
to provide a mechanism to allow users to move images around reasonable 
but once an image is present on a reasonable filesystem, we should more 
or less get the heck out of the way.

> > By creating two code paths within qcow2. 
>
> You're creating two code paths for users.

No, I'm creating a single path: QED.

There are already two code paths: raw and qcow2.  qcow2 has had such a 
bad history that for a lot of users, it's not even a choice.

Today, users have to choose between performance and reliability or 
features.  QED offers an opportunity to be able to tell users to just 
always use QED as an image format and forget about raw/qcow2/everything 
else.

You can say, let's just make qcow2 better, but we've been trying that 
for years and we have an existence proof that we can do it in a straight 
forward fashion with QED.A new format doesn't introduce much additional 
complexity.  We provide image conversion tool and we can almost 
certainly provide an in-place conversion tool that makes the process 
very fast.

> It requires users to make a decision.  By the time qed is ready for 
> mass deployment, 1-2 years will have passed.  How many qcow2 images 
> will be in the wild then?  How much scheduled downtime will be needed?

Zero if we're smart.  You can do QED stream + live migration to do a 
live conversion from raw to QED.

>   How much user confusion will be caused?

User confusion is reduced if we can make strong, clear statements: all 
users should use QED even if they care about performance.  Today, 
there's mass confusion because of the poor state of qcow2.

> Virtualization is about compatibility.  In-guest compatibility first, 
> but keeping the external environment stable is also important.  We 
> really need to exhaust the possibilities with qcow2 before giving up 
> on it.

IMHO, we're long past exhausting the possibilities with qcow2.  We still 
haven't decided what we're going to do for 0.13.0.  Are we going to ship 
qcow2 with awful performance (a 15 minute operation taking hours) or 
with compromised data integrity?

It's been this way for every release since qcow2 existed.  Let's not let 
sunk cost cloud our judgement here.

qcow2 is not a properly designed image format.  It was a weekend hacking 
session from Fabrice that he dropped in the code base and never really 
finished doing what he originally intended.  The improvements that have 
been made to it are almost at the heroic level but we're only hurting 
our users by not moving on to something better.

Regards,

Anthony Liguori