From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48313 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDH73-0002cy-U8 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 09:41:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDH6x-0000rQ-NZ for qemu-devel@nongnu.org; Tue, 02 Nov 2010 09:41:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDH6x-0000qC-EF for qemu-devel@nongnu.org; Tue, 02 Nov 2010 09:41:15 -0400 Message-ID: <4CD01527.7090202@redhat.com> Date: Tue, 02 Nov 2010 14:41:59 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal References: <1288030956-28383-1-git-send-email-ryanh@us.ibm.com> <20101029150336.GJ22904@us.ibm.com> <20101029165044.GM22904@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Stefan Hajnoczi , Anthony Liguori , Ryan Harper , qemu-devel@nongnu.org, "Michael S. Tsirkin" Am 02.11.2010 10:40, schrieb Markus Armbruster: > Ryan Harper writes: > >> * Markus Armbruster [2010-10-29 11:11]: >>> Ryan Harper writes: >>> >>> Regardless of the way we choose, we need to think very clearly on how >>> exactly device models should behave when their host part is missing or a >>> zombie, and how that behavior appears in the guest. >>> >>> For net, making it look exactly like a yanked out network cable would >>> make sense to me. >>> >>> What about block? >> >> It seems to me that for block it's like cdrom with no disk, floppy with >> no media, hard disk that's gone bad. I think we we throw EIO back; it's >> handled gracefully enough. This is what happens when you do a >> drive_unplug with my patch; the application using the device gets IO >> errors. That's expected if a drive were to suddently fail (which is >> what this looks like). And certainly there is some responsibility >> at the mgmt console to ensure you're not unplugging a drive that you are >> currently using. > > Total drive failure works for me. > > "No media" is cute, but it's possible only for drives with removable > media. I'd rather have all drives behave the same, whether their media > is removable or not. But I think we need some way to eject the medium without destroying the whole device. If you handle it as "device broken", you need another command for keeping the device, but ejecting the medium, unplugging the network cable, etc. We have "eject" for block today, but it needs a drive and not a blockdev (and I'm not even sure it really does what I'm thinking of, once again) Kevin