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

[Max Reitz <mreitz@redhat.com>]

On 06.05.2015 18:20, Paolo Bonzini wrote:
>
> On 06/05/2015 18:12, Max Reitz wrote:
>> I very much think it would be worth fixing, if there wasn't the problem
>> with legitimate use cases throwing unnecessary warnings.
> Right.
>
>> 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).
> There's another thing to check.  In the BZ you linked you got an EINVAL
> or EIO.  Why didn't you get an ENOSPC?

Because qcow2 tries to write beyond the end of the file; the NBD client 
implementation passes that on to the server, and the server simply 
reports an error (which the NBD client turns into EIO).

We could make the NBD client detect this condition and report ENOSPC 
immediately. But I don't think this would improve matters, for people 
would then complain "Linux reports 'no space left on device' in qemu, 
while df reports that there is enough space available". It's the same 
thing, people don't know what they're doing and nobody warned them that 
what they are doing might be wrong.

> Can you check if virtio-scsi
> gives ENOSPC?

In which configuration? Using virtio-scsi on top of qcow2 on top of some 
SCSI passthrough block driver?

> If so, you could perhaps only warn for werror=report.  But even then,
> there are legitimate cases where you want the guest to see the ENOSPC.
> In fact, that's the reason why virtio-scsi converts ENOSPC to a SCSI
> "SPACE ALLOCATION FAILED" sense code. :)

Sounds like we ought to make NBD return ENOSPC no matter the fate of 
this series.

The problem with only warning for a certain non-default configuration is 
that people who don't know what they are doing are more likely to use 
the default configuration, so I'd like the warning to appear then.

>> 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.
> I don't know...  But then, I'm not a maintainer of this code. :)

Well, this is not about this code in particular, but more about qemu's 
interface design in general, so I'm grateful about any opinion on it. :-)

Max