Re: [Qemu-devel] Re: [PATCH] For AIO return -ENOSPC on short write
On Tue, Feb 22, 2011 at 05:59:01PM +0100, Paolo Bonzini wrote: On 02/22/2011 04:16 PM, Stefan Hajnoczi wrote: Yes it is. It doesn't explain it though. The code involved here is linux-aio.c and will be qcow2's bs-file. That ought to be a host_device and AFAIK that is not growable. So I wanted to figure out why we're even getting this far. I expected the request to get rejected in block.c when checking the range against the host_device. Possibly a COW logical volume can give short writes on disk full? It shouldn't. If it does that needs fixing.
[Qemu-devel] Re: [PATCH] For AIO return -ENOSPC on short write
Am 22.02.2011 11:18, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
linux-aio.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/linux-aio.c b/linux-aio.c
index 68f4b3d..d9c0225 100644
--- a/linux-aio.c
+++ b/linux-aio.c
@@ -32,6 +32,7 @@ struct qemu_laiocb {
ssize_t ret;
size_t nbytes;
int async_context_id;
+int type;
QLIST_ENTRY(qemu_laiocb) node;
};
@@ -62,6 +63,9 @@ static void qemu_laio_process_completion(struct
qemu_laio_state *s,
if (ret != -ECANCELED) {
if (ret == laiocb-nbytes)
ret = 0;
+else if ((laiocb-type == QEMU_AIO_WRITE) (ret = 0)
+ (ret laiocb-nbytes))
+ret = -ENOSPC;
else if (ret = 0)
ret = -EINVAL;
Isn't there a way to get the real error code instead of just making it
up more cleverly? Like retrying for the rest of the request?
Kevin
[Qemu-devel] Re: [PATCH] For AIO return -ENOSPC on short write
On 02/22/11 12:44, Kevin Wolf wrote:
@@ -62,6 +63,9 @@ static void qemu_laio_process_completion(struct
qemu_laio_state *s,
if (ret != -ECANCELED) {
if (ret == laiocb-nbytes)
ret = 0;
+else if ((laiocb-type == QEMU_AIO_WRITE) (ret = 0)
+ (ret laiocb-nbytes))
+ret = -ENOSPC;
else if (ret = 0)
ret = -EINVAL;
Isn't there a way to get the real error code instead of just making it
up more cleverly? Like retrying for the rest of the request?
Kevin
I guess we could retry the last part of the request, but if we already
have an error, it seems silly to try to rewrite the same stuff again
just to obtain the error code.
I looked through the aio calls and I didn't find any obvious way to
retrieve the error code, but maybe I missed something?
Cheers,
Jes
Re: [Qemu-devel] Re: [PATCH] For AIO return -ENOSPC on short write
On 02/22/2011 01:45 PM, Jes Sorensen wrote:
On 02/22/11 12:44, Kevin Wolf wrote:
@@ -62,6 +63,9 @@ static void qemu_laio_process_completion(struct
qemu_laio_state *s,
if (ret != -ECANCELED) {
if (ret == laiocb-nbytes)
ret = 0;
+else if ((laiocb-type == QEMU_AIO_WRITE) (ret= 0)
+ (ret laiocb-nbytes))
+ret = -ENOSPC;
else if (ret= 0)
ret = -EINVAL;
Isn't there a way to get the real error code instead of just making it
up more cleverly? Like retrying for the rest of the request?
Kevin
I guess we could retry the last part of the request, but if we already
have an error, it seems silly to try to rewrite the same stuff again
just to obtain the error code.
Why? It's the standard Unix idiom. Keep writing until you either
complete your request or get an error. We don't do this here, and
instead invent an error.
Admittedly it's harder to do.
I looked through the aio calls and I didn't find any obvious way to
retrieve the error code, but maybe I missed something?
The existing code already has it: if ret is negative, that's what we return.
What you have to do on a short read or write is to schedule a new
request that starts from the point where this completion ends, and let
the completion of the new request return the error (or perhaps succeed).
--
error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH] For AIO return -ENOSPC on short write
On 02/22/2011 04:16 PM, Stefan Hajnoczi wrote: Yes it is. It doesn't explain it though. The code involved here is linux-aio.c and will be qcow2's bs-file. That ought to be a host_device and AFAIK that is not growable. So I wanted to figure out why we're even getting this far. I expected the request to get rejected in block.c when checking the range against the host_device. Possibly a COW logical volume can give short writes on disk full? Paolo
