From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCUtc-0008Rb-OW for qemu-devel@nongnu.org; Thu, 22 Aug 2013 09:26:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCUtT-0005gE-J0 for qemu-devel@nongnu.org; Thu, 22 Aug 2013 09:25:52 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:50454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCUtT-0005fn-0Q for qemu-devel@nongnu.org; Thu, 22 Aug 2013 09:25:43 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Aug 2013 23:22:26 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 948FA357804E for ; Thu, 22 Aug 2013 23:25:37 +1000 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7MDPQvo9306508 for ; Thu, 22 Aug 2013 23:25:26 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7MDPaff003514 for ; Thu, 22 Aug 2013 23:25:36 +1000 Date: Thu, 22 Aug 2013 18:55:51 +0530 From: Bharata B Rao Message-ID: <20130822132551.GC2755@in.ibm.com> References: <1377050567-19122-1-git-send-email-asias@redhat.com> <20130821152440.GB18303@stefanha-thinkpad.redhat.com> <5214DF5B.50203@redhat.com> <20130822055947.GB24870@in.ibm.com> <20130822074846.GC10412@stefanha-thinkpad.redhat.com> <5215D4A7.60501@redhat.com> <20130822095542.GA2755@in.ibm.com> <5215E150.7000800@redhat.com> <20130822102829.GB2755@in.ibm.com> <5215F2EF.4060106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5215F2EF.4060106@redhat.com> Subject: Re: [Qemu-devel] [PATCH] block: Fix race in gluster_finish_aiocb Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Vijay Bellur , Stefan Hajnoczi , qemu-devel@nongnu.org, Stefan Hajnoczi , Asias He , MORITA Kazutaka On Thu, Aug 22, 2013 at 01:15:59PM +0200, Paolo Bonzini wrote: > Il 22/08/2013 12:28, Bharata B Rao ha scritto: > > On Thu, Aug 22, 2013 at 12:00:48PM +0200, Paolo Bonzini wrote: > >> 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 > > > > 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. That's the reason we return -EIO and make the disk inaccessible when this failure happens. My question was if it is ok to abort the VM when IO to one of the disks fails ? But, if you think it is not worth handling such errors then may be we can drop this elaborate and race-prone error recovery and just abort. Regards, Bharata.