Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols

[Max Reitz]

On 06.05.2015 17:30, Paolo Bonzini wrote:
> On 06/05/2015 15:04, Max Reitz wrote:
> > > Introducing a warning for a normal QEMU invocation is a bit weird.
> > >
> > > What is the point of this series?  Were users confused that they hit
> > > ENOSPC?
> > Users were confused when exporting a qcow2 image using nbd-server
> > instead of qemu-img, and then accessing that NBD export with qemu
> > (subsequently getting I/O errors on guest writes, if the image is not
> > yet fully allocated): http://bugzilla.redhat.com/show_bug.cgi?id=1090713
> I think NBD exports of non-raw images falls within the case of "user
> should know what they're doing".  In particular, you don't even need
> metadata preallocation, you just need a "truncate -s10G file.qcow2"
> before invoking nbd-server.

Well, actually, you need to export it with qemu-nbd instead of 
nbd-server; which this series is trying to tell the users.

> So I think it's not worth fixing this, even though I see how it can be a
> minor UI/UX issue.

I very much think it would be worth fixing, if there wasn't the problem 
with legitimate use cases throwing unnecessary warnings.

I remember having a discussion with Kevin about this series (v1) 
regarding qcow2 on LVM; I think my point was that the warning is 
basically still correct, or only needs rewording (oops, I guess I did 
forget that in v2). If you are using qcow2 on LVM, you need to know 
exactly what you are doing, so a warning about this is indeed 
appropriate (in my opinion, that is).

So I think if we can word the warning in a way to make it clear that 
there are legitimate use cases, but you need to know what you are doing, 
I think it's worth having this warning. Users who know what they're 
doing won't be surprised or at least will know what it means, while 
users who don't know what it means most probably don't know what they're 
doing and thus the warning is appropriate for them.

And if you're using management software (which hopefully does know what 
it's doing), the warning shouldn't be prominently visible anyway (in 
case of using libvirt, stderr is written to a log file, right?).

Max