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 errors.
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 it
means
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 text
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 return value
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.
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 write errors. Otherwise
the errno
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, but
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
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,
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. I don't see why a metadata
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 this occurs.
I think that's
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
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
guest OS effectively just lock up when
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
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. Reporting errors back to the host has its own
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. Reporting
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
handling):
Disk full is a fundamentally unfriendly
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
19 matches
Mail list logo
