From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFqVG-0006IZ-3Z for qemu-devel@nongnu.org; Mon, 26 Jan 2015 15:43:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFqVC-0000YF-Tl for qemu-devel@nongnu.org; Mon, 26 Jan 2015 15:43:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFqVC-0000Y9-LC for qemu-devel@nongnu.org; Mon, 26 Jan 2015 15:43:18 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0QKhHUe010511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 26 Jan 2015 15:43:18 -0500 Message-ID: <54C6A6E4.8060000@redhat.com> Date: Mon, 26 Jan 2015 15:43:16 -0500 From: Max Reitz MIME-Version: 1.0 References: <1422300468-16216-1-git-send-email-mreitz@redhat.com> <1422300468-16216-5-git-send-email-mreitz@redhat.com> <54C6A622.9010902@redhat.com> In-Reply-To: <54C6A622.9010902@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/21] block: Add bdrv_close_all() handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: Kevin Wolf , Markus Armbruster , Stefan Hajnoczi On 2015-01-26 at 15:40, Paolo Bonzini wrote: > > On 26/01/2015 20:27, Max Reitz wrote: >> However, this was wrong: With the NBD attached to some BB, it >> should stay attached until the NBD export is removed or the server >> stopped; medium ejection should have nothing to do with this (other than >> the NBD server not being able to read data while the virtual is open, if >> there is one (and there is one if the NBD server is attached to the same >> BB as a guest device with a tray is; which is correct behavior because >> attaching an NBD server to a guest-used BB should result in the NBD >> server behaving exactly the same as the guest device)). > Not entirely; use of close notifiers was on purpose. We do not want the > NBD client to start reading data from a different medium without noticing. > > If the NBD server is attached to the BDS, it should keep serving the BDS. The problem is that it is no longer attached to the BDS, but to the BB. > If the NBD server is attached to the BB, the clients must have a way to > notice the medium change, and so far the solution was to close the > connection. I'd be wary to change this, though I understand where you > come from. Yes, I understand. However, I think the NBD server has to be attached to a separate BB if medium changes should not be allowed; but this would break backwards compatibility... I think to retain compatibility we could either just do what we always did (although I find it wrong), or we could simply set up an eject blocker when attaching an NBD server to a BB. What do you think? Max