From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:40653)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QogJ7-0006Ns-3f
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:36:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QogJ6-0001Mp-14
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:36:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:25398)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QogJ5-0001ME-P1
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:36:39 -0400
Date: Wed, 3 Aug 2011 15:36:34 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20110803153634.6fbf2c13@doriath>
In-Reply-To: <20110803182630.GA9899@lst.de>
References: <1312384765-721-1-git-send-email-lcapitulino@redhat.com>
	<20110803163131.GA8411@lst.de> <20110803151138.28850d1c@doriath>
	<20110803182630.GA9899@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 0/5]: QMP: Proper thin provisioning
 support
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: kwolf@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, armbru@redhat.com

On Wed, 3 Aug 2011 20:26:30 +0200
Christoph Hellwig <hch@lst.de> wrote:

> On Wed, Aug 03, 2011 at 03:11:38PM -0300, Luiz Capitulino wrote:
> > > > It's already possible for QMP clients to implement this feature by using
> > > > the BLOCK_IO_ERROR event. However, the event can be missed. When this
> > > > happens QMP clients need a way to query if any block device has hit a
> > > > no space condition.
> > > 
> > > We have a mode where we stop the VM when it hits ENOSPC, and that is
> > > the only reliably way to handle it. 
> > 
> > This series just complements that mode by allowing a mngt application
> > to query which device triggered the ENOSPC. Well, that's my intention :)
> 
> Oh, so you only plan to use the QMP command post-mortem?  That makes a lot
> more sense.  

Yes. Calling it 'proper thin provisioning support' was too ambitious from
my part.

> But relying on that fact should also help to simplify the
> implementation and make it more robust by storing the error code from
> the same place that we stop them VM.

Yes, I think I'll do that.