Re: [Xen-devel] [PATCH] Add a --force option to detach operations

["Glauber de Oliveira Costa" <glommer@xxxxxxxxx>]

On 12/14/06, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
> On 13/12/06 22:35, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> wrote:
>
> > The following patch adds a --force option to detach operations. It
> > avoids the device being held forever when frontend fails.
>
> Looks good. I think --force should be more brutal (i.e., assume that we have
> already politely requested the disconnection, if that's what we really
> wanted).
How can we be more brutal than that ? The only non-brutal thing I've put there
is denying disconnection when still in Connected state. But if for
some reason the frontend does not want to disconnect, then the tools
have no power over it. It can simply crash guest.

Example: attach a device, mount it at guest, and try to detach it
using --force. It should not force it, as it crashes the guest.
> Apart from that, we should remember that if we need to use --force then it
> probably indicates a problem in the frontend driver. If you can repro a
> situation that requires --force then we should investigate that (and work
> out a patch for blkfront).
Not exactly. The example I'm tracking is as follow:
* try attaching a file:///<valid_file> as sda, after modprobing
sd_mod at guest.
* guest is not able to allocate it a major, and fails like this:

Registering block device major 8
register_blkdev: cannot get major 8 for sd
xen_blk: can't get major 8 with name sd

Besides, there are many situations in which the underlying block layer
can fail (out of memory, and so on). And it does not necessarily means
a bug in the frontend device.

I do however agree that in the general case, it is a good indicator.

--
Glauber de Oliveira Costa.
"Free as in Freedom"

Add your comments to GPLv3 at:
http://gplv3.fsf.org/comments/gplv3-draft-2.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel