qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from devic


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal
Date: Tue, 02 Nov 2010 14:41:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

Am 02.11.2010 10:40, schrieb Markus Armbruster:
> Ryan Harper <address@hidden> writes:
> 
>> * Markus Armbruster <address@hidden> [2010-10-29 11:11]:
>>> Ryan Harper <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]