From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHX5a-0006Sc-1S for qemu-devel@nongnu.org; Wed, 04 May 2011 04:05:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHX5Y-0003A0-ST for qemu-devel@nongnu.org; Wed, 04 May 2011 04:05:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHX5Y-00039t-Ir for qemu-devel@nongnu.org; Wed, 04 May 2011 04:05:40 -0400 Message-ID: <4DC1096C.6040806@redhat.com> Date: Wed, 04 May 2011 10:08:12 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20110503200339.GA7838@random.random> In-Reply-To: <20110503200339.GA7838@random.random> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] ide: cleanup warnings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org, Christoph Hellwig Am 03.05.2011 22:03, schrieb Andrea Arcangeli: > Hello, > > This is just a minor cleanup adding \n. Thanks, applied to the block branch. > On a side note, it was good idea to keep it under DEBUG_IDE because if > iscsi server reboots or goes down, this would generate a flood of > errors if it's enabled (a flood of these warnings would have been > shown with DEBUG_IDE on in such a condition). Isn't it a bug that qemu_aio_flush() doesn't clear aiocb/status? Should we move the ide_set_inactive() call from ide_dma_error to ide_dma_cb? > So I've also been wondering if it's safe to ignore these warnings when > the iscsi server is down. The error is delivered up to ide which > simulates a I/O error for the guest (something like > BM_STATUS_PIO_RETRY), so then it should be up to the guest OS to retry > long enough and deal with it without corrupting the guest filesystem > image. Often local filesystems in the guest (ext4/brfs/xfs etc...) > won't be heavily tested for I/O errors. So it would be somewhat safer > to retry on the qemu side without passing errors up to the guest, OTOH > the guest ide driver might eventually notice a DMA timeout if the I/O > doesn't complete in a timely fashion, so retrying indefinitely in qemu > aio layer wouldn't be a definitive solution to avoid triggering guest > os bugs... So in the end this is probably the best way we can handle > the iscsi server disconnect with ide. This is actually something controlled by werror. With werror=stop, the VM is stopped and the guest never sees the error, but qemu retries. With werror=report, the error is reported to the guest which can retry. Kevin