From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MQpcD-0006Om-8c
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 17:32:45 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MQpc8-0006Go-75
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 17:32:44 -0400
Received: from [199.232.76.173] (port=50841 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MQpc7-0006GO-ST
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 17:32:39 -0400
Received: from verein.lst.de ([213.95.11.210]:42503)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MQpc7-00043V-DZ
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 17:32:39 -0400
Date: Tue, 14 Jul 2009 23:32:35 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] raw-posix: Handle errors in raw_create
Message-ID: <20090714213235.GC7580@lst.de>
References: <1247323417-17395-1-git-send-email-weil@mail.berlios.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1247323417-17395-1-git-send-email-weil@mail.berlios.de>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Weil <weil@mail.berlios.de>
Cc: QEMU Developers <qemu-devel@nongnu.org>

On Sat, Jul 11, 2009 at 04:43:37PM +0200, Stefan Weil wrote:
> In qemu-iotests, some large images are created using qemu-img.
> 
> Without checks for errors, qemu-img will just create an
> empty image, and later read / write tests will fail.
> 
> With the patch, failures during image creation are detected
> and reported.

Yeah, we should handle the failures and your patch looks correct in
that respect.  But returning close error codes is in general
not very useful.  There's not much we can do about them, in they
might override the more useful ftruncate error code.

So I'd rather do something like the following:

    if (fd < 0) {
        return -errno;
    }
 
    if (ftruncate(fd, total_size * 512) != 0) {
        result = -errno;
    }

    close(fd);
    return result;