From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuIE-00081g-Ne for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:40:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDuI8-0002iJ-Sg for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:40:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuI8-0002hW-K8 for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:40:28 -0400 Message-ID: <50584184.5080602@redhat.com> Date: Tue, 18 Sep 2012 11:40:20 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <539633110.1300350.1347959367353.JavaMail.root@redhat.com> In-Reply-To: <539633110.1300350.1347959367353.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] ping Re: [RFC PATCH 00/13] Embedded NBD server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: stefanha@gmail.com, qemu-devel@nongnu.org, Markus Armbruster Am 18.09.2012 11:09, schrieb Paolo Bonzini: >>> 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). I think I can buy this, but please add it to the commit message. >>> 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. Hm, I guess so, at least on the lowest level. The only thing I know for certain is that maintaining compatibility for the old commands will be fun, but if possible at all we shouldn't let that compromise our design. Kevin