From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=51412 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PelAu-0002Kz-Us
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 04:14:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1PelAt-0002Js-RO
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 04:14:56 -0500
Received: from verein.lst.de ([213.95.11.210]:53820)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1PelAt-0002Ie-J5
	for qemu-devel@nongnu.org; Mon, 17 Jan 2011 04:14:55 -0500
Date: Mon, 17 Jan 2011 10:14:46 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/3] block: tell drivers about an image resize
Message-ID: <20110117091446.GA19062@lst.de>
References: <20110114162044.GA19114@lst.de> <20110114162104.GB19184@lst.de>
	<20110114210611.GI6249@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110114210611.GI6249@us.ibm.com>
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: Ryan Harper <ryanh@us.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

> Do we want to check to ensure the size_changed flag isn't set before
> doing a second resize event?  I'm wondering if the truncate takes
> $longtime and user gets impatient and issues a second resize command.
> How should we respond?  Ignore it?  queue it up? 

The truncate is synchronous and the monitor command won't return before
it's done.  The interfact might be a bit cleaner if we'd just pass the
reason for the change callback as another argument.  I'll do that for
the next respin.

> Is there any other path that invokes bdrv_truncate?  If so, do we want
> invoke the call back in those scenarios or only if the truncate is
> initiated from the monitor invocation?

Currently only the qemu-img and qemu-io tools invooke bdrv_truncate.
But if we grow new users we should always tell the driver/guest about it
so that it knows about the size change.