From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52614 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PSB43-0004ja-20
	for qemu-devel@nongnu.org; Mon, 13 Dec 2010 11:15:51 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1PSB41-0000lb-Tv
	for qemu-devel@nongnu.org; Mon, 13 Dec 2010 11:15:50 -0500
Received: from verein.lst.de ([213.95.11.210]:37507)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1PSB41-0000l1-K6
	for qemu-devel@nongnu.org; Mon, 13 Dec 2010 11:15:49 -0500
Date: Mon, 13 Dec 2010 17:15:47 +0100
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20101213161547.GA6498@lst.de>
References: <20101125135657.GA2814@lst.de> <20101201153504.GA6056@lst.de>
	<20101201153514.GA6310@lst.de> <4CF78D1D.3060107@redhat.com>
	<20101210133843.GA28846@lst.de> <4D0644BF.3020701@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D0644BF.3020701@redhat.com>
Subject: [Qemu-devel] Re: [PATCH 1/5] block: add discard support
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.nongnu.org/archive/html/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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Mon, Dec 13, 2010 at 05:07:27PM +0100, Paolo Bonzini wrote:
> On 12/10/2010 02:38 PM, Christoph Hellwig wrote:
> >if it's smaller than the block size we'll zero out the remainder of
> >the block.
> 
> I think it should fail at VM startup time, or even better do nothing at all.

What should fail?

> When you write in the middle of an absent block, and a partially-zero 
> block is created, this is not visible: a read cannot see the difference 
> between "all zeros because it's sparse" and "all zeros because it's zero".

You can not see from a VM if a block is not allocated or zeroed.  Then
again we'll never create a fully zeroed block anyway unless we get
really stupid discard patterns from the guest OS.

> If I ask you to (optionally) punch a 1kb hole but all you can do is 
> punch a 2kb hole, I do care about the second kilobyte of data.  Since 
> the hole punching of bdrv_discard is completely optional, it should not 
> be done in this case.

Of course we do not discard the second KB in that case.  If you issue
a 1k UNRSVSP ioctl on a 2k block size XFS filesystem it will zero
exactly the 1k you specified, which is required for the semantics of the
ioctl.  Yes, it's not optimal, but qemu can't easily know what block
size the underlying filesystem has.