From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq2KJ-0003ne-N1 for qemu-devel@nongnu.org; Wed, 06 May 2015 12:37:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq2KE-0003FE-Ik for qemu-devel@nongnu.org; Wed, 06 May 2015 12:37:39 -0400 Message-ID: <554A4349.10301@redhat.com> Date: Wed, 06 May 2015 18:37:29 +0200 From: Max Reitz MIME-Version: 1.0 References: <1426791801-9042-1-git-send-email-mreitz@redhat.com> <20150505094606.GB29818@stefanha-thinkpad.redhat.com> <554A1160.7020200@redhat.com> <554A3395.7050509@redhat.com> <554A3D7B.3040603@redhat.com> <554A3F37.9080704@redhat.com> In-Reply-To: <554A3F37.9080704@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org 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