Il 22/08/2013 11:55, Bharata B Rao ha scritto:
> This was the first apporach I had. I used to abort when writes to pipe
> fail. But there were concerns raised about handling the failures gracefully
> and hence we ended up doing all that error handling of completing the aio
> with -EIO, closing the pipe and making the disk inaccessible.
>
>> > Under what circumstances could it happen?
> Not very sure, I haven't seen that happening. I had to manually inject
> faults to test this error path and verify the graceful recovery.
Looking at write(2), it looks like it is impossible
EAGAIN or EWOULDBLOCK
can't happen, blocking file descriptor
EBADF, EPIPE
shouldn't happen since the device is drained before
calling qemu_gluster_close.
EDESTADDRREQ, EDQUOT, EFBIG, EIO, ENOSPC
cannot happen for pipes
EFAULT
abort would be fine
EINTR
handled by qemu_write_full
EINVAL
cannot happen (unless the pipe is closed and the
file descriptor recycled, but see EBADF above)
The pipe(7) man page doesn't seem to add any more errors.
Paolo
