qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] ping Re: [RFC PATCH 00/13] Embedded NBD server


From: Paolo Bonzini
Subject: Re: [Qemu-devel] ping Re: [RFC PATCH 00/13] Embedded NBD server
Date: Tue, 18 Sep 2012 05:09:27 -0400 (EDT)

> > Luckily removable media are usually not too interesting, so a
> > slightly suboptimal behavior is okay as long as it does not break the
> > important use cases---mostly migration without shared storage, where also
> > uninteresting images have to be mirrored or exposed via NBD.  Those
> > should be covered by bdrv_in_use.
> 
> It sounds like it could be acceptable, yes. But what's even the
> motivation to close the server on bdrv_close? The commit message is a
> bit... well, not just terse, but even empty.

The motivation is two-fold:

1) for device hot-unplug, not closing the server would impede removal
of the blockdev until after all clients have closed their connections.

2) for the removable media case, clients risk reading data from two
different images and merging it somehow.

In either case (hot-unplug and eject) after bdrv_close I/O requests would
return ENOMEDIUM, so there is not much benefit in leaving the connection
open.  Clients can reconnect with the understanding that the medium has
changed (medium change is not part of the NBD specification, but we can
retrofit it this way).

> The standard case for closing images is that qemu exits. In this case,
> the NBD server would automatically exit as well. An interesting case
> for the NBD server would be when the migration has completed; but do we
> even get a bdrv_close there?

No, you don't.

> > Yes, though a lot of these could be moved to "filters" and use
> > whatever filter-specific method is there (e.g. a filter bdrv_close).
> > This circles back to the question of whether bdrv_close kills filters
> > or only the base image...
> 
> Note that after completing the refactoring, we'll only have one combined
> bdrv_close/delete function and so there won't be BlockDriverStates
> that are closed. In this case, I think it's quite obvious that not closing
> the filters wouldn't make any sense.

Does that mean that any I/O throttling must be applied again on every
medium change?  That would be a behavioral change.

Paolo



reply via email to

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