On Thu, Feb 21, 2008 at 11:28:23AM -0600, [EMAIL PROTECTED] wrote:
> On Thu, Feb 21, 2008 at 05:24:10PM +, Daniel P. Berrange wrote:
> > On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
> > > > > Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
> > > > > error (the r
On Thu, Feb 21, 2008 at 05:24:10PM +, Daniel P. Berrange wrote:
> On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
> >
> > "Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> > > On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
> > > Content-Description: message body
On Thu, Feb 21, 2008 at 12:19:22PM -0500, Ben Taylor wrote:
>
> "Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
> > Content-Description: message body text
> > > bdrv_flush is declared to return void, but this is wrong because i
"Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
> Content-Description: message body text
> > bdrv_flush is declared to return void, but this is wrong because it
> > means that the implementations have nowhere to report their erro
Sometimes the guest intentionally seeks the error. Example?
TrueCrypt 5.0 supports encryption of the full system disk. To get the real
size of the disk, the truecrypt driver queries the number of blocks of the
disk, but then tries to read after the last block, until it gets an error.
Qemu hangs in
On Wednesday 20 February 2008 01:01:33 pm Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> > On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
> >> Ian Jackson wrote:
> >>> Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error
Daniel P. Berrange wrote:
On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
Ian Jackson wrote:
Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer.
On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
> Ian Jackson wrote:
> > Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> > > Disk full is a fundamentally unfriendly situation to be in. There is no
> > > good
>
Paul Brook wrote:
> > Is savevm-upon-disk-full a realistic prospect?
>
> Not particularly useful. If you're run out of disk space, chances are that
> savevm will also fail.
I'm imagining (a) that the savevm space is preallocated, or (b) is on
a different disk.
-- Jamie
> Is savevm-upon-disk-full a realistic prospect?
Not particularly useful. If you're run out of disk space, chances are that
savevm will also fail.
Paul
Ian Jackson wrote:
> Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> > Disk full is a fundamentally unfriendly situation to be in. There is no
> > good
> > answer. Reporting errors back to the host has its own set of problems. Many
>
Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> Disk full is a fundamentally unfriendly situation to be in. There is no good
> answer. Reporting errors back to the host has its own set of problems. Many
> guest OS effectively just lock up when th
> Write errors for non-raw formats can easily be caused by a disk full
> situation on the host. Killing the guest hard is unfriendly for that
> situation.
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting errors back to the host has its own set of pro
Avi Kivity writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> For non-raw formats, you can pass through errors on data, but it is
> impossible to recover on metadata errors, so dying on I/O error should
> be fine.
You mean metadata write errors I assume.
Paul Brook wrote:
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, the
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give write errors. Otherwise
> > the errno value and other important information will be lost, which
> > makes debugging hard.
>
> If by 'qemu console' you mean stderr, then fine,
Daniel P. Berrange writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error
handling"):
> On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
> bdrv_flush is declared to return void, but this is wrong because it
> means that the implementations have nowhere to report their errors.
> Indeed, the implementations generally ignore errors.
>
>
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functi
19 matches
Mail list logo
