qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator
Date: Tue, 9 Sep 2014 10:27:33 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 08.09.2014 um 18:57 hat Luiz Capitulino geschrieben:
> On Mon, 8 Sep 2014 17:33:18 +0200
> Kevin Wolf <address@hidden> wrote:
> 
> > Am 08.09.2014 um 16:42 hat Luiz Capitulino geschrieben:
> > > On Fri, 29 Aug 2014 16:07:27 -0400
> > > Luiz Capitulino <address@hidden> wrote:
> > > 
> > > > Management software, such as RHEV's vdsm, want to be able to allocate
> > > > disk space on demand. The basic use case is to start a VM with a small
> > > > disk and then the disk is enlarged when QEMU hits a ENOSPC condition.
> > > > 
> > > > To this end, the management software has to be notified when QEMU
> > > > encounters ENOSPC. The solution implemented by this commit is simple:
> > > > it extends the BLOCK_IO_ERROR with a 'nospace' key, which is true
> > > > when QEMU is stopped due to ENOSPC.
> > > > 
> > > > Note that support for querying this event is already present in
> > > > query-block by means of the 'io-status' key. Also, the new 'nospace'
> > > > BLOCK_IO_ERROR field shares the same semantics with 'io-status',
> > > > which basically means that werror= has to be set to either
> > > > 'stop' or 'enospc' to enable 'nospace'.
> > > > 
> > > > Finally, this commit also updates the 'io-status' key doc in the
> > > > schema with a list of supported device models.
> > > > 
> > > > Signed-off-by: Luiz Capitulino <address@hidden>
> > > 
> > > Kevin, are you going to take this via block layer tree?
> > 
> > Yes, thanks, I've applied it now.
> > 
> > What was our conclusion wrt the human-readable strerror() string for
> > debugging? Didn't we want to add that as well?
> 
> I can do it on top of this patch. So, just adding a new field for this
> is fine?

I think so. Perhaps we should give it an 'x-' name to make clear that
it's a debugging help and not supposed to be parsed by management tools.
Or would that be abuse of that namespace?

The alternative solution (or actually we could do both) would be to
store it somewhere in bs and put it into query-block.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]