From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwq7w-0007EC-1l for qemu-devel@nongnu.org; Thu, 12 Nov 2015 06:33:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwq7q-0004ht-DC for qemu-devel@nongnu.org; Thu, 12 Nov 2015 06:33:15 -0500 Date: Thu, 12 Nov 2015 19:33:03 +0800 From: Fam Zheng Message-ID: <20151112113303.GU4082@ad.usersys.redhat.com> References: <1446799373-6144-1-git-send-email-pl@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1446799373-6144-1-git-send-email-pl@kamp.de> Subject: Re: [Qemu-devel] [PATCH V3 0/6] ide: avoid main-loop hang on CDROM/NFS failure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, qemu-block@nongnu.org, stefanha@gmail.com, jcody@redhat.com, qemu-devel@nongnu.org, jsnow@redhat.com On Fri, 11/06 09:42, Peter Lieven wrote: > This series aims at avoiding a hanging main-loop if a vserver has a > CDROM image mounted from a NFS share and that NFS share goes down. > Typical situation is that users mount an CDROM ISO to install something > and then forget to eject that CDROM afterwards. > As a consequence this mounted CD is able to bring down the > whole vserver if the backend NFS share is unreachable. This is bad > especially if the CDROM itself is not needed anymore at this point. If a storage backend is lost, would QEMU hang on guest reboot with this patch? If so, just for understanding the problem, what is the use case this series addresses? The code looks good to me apart from the two questions I left, and that I didn't fully understand the elementary transfer part. Thanks, Fam