On Thu, Aug 22, 2013 at 03:27:35PM +0200, Paolo Bonzini wrote: > >>>> 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 > >>> > >>> In the case where we have separate system and data disks and if error > >>> (EFAULT) > >>> happens for the data disk, don't we want to keep the VM up by gracefully > >>> disabling IO to the data disk ? > >> > >> EFAULT means the buffer address is invalid, I/O error would be EIO, but... > >> > >>> I remember this was one of the motivations to > >>> handle this failure. > >> > >> ... this write is on the pipe, not on a disk. > > > > Right. Failure to complete the write on the pipe means that IO done to the > > disk didn't complete and hence to the VM it is essentially a disk IO > > failure. > > The question is, can the write to the pipe actually fail? Not just "in > practice not" according to the documented errors, it seems to me that it > cannot.
May be I am dragging this a bit, but since we are at it, let me make one last observation here :) The buffer in question here is the GlusterAIOCB pointer that gets passed back and forth between QEMU and gluster thro' glfs_pwritev_async and associated callback gluster_finish_aiocb. Isn't there a possibility that gluster will not give us back the same pointer during callback due to some errors on the gluster side ? Unlikely but possible ? Regards, Bharata.
