From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPtTC-0004XJ-72 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 05:08:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPtTB-0005pb-2F for qemu-devel@nongnu.org; Mon, 14 Nov 2011 05:08:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPtTA-0005pX-RQ for qemu-devel@nongnu.org; Mon, 14 Nov 2011 05:08:53 -0500 Date: Mon, 14 Nov 2011 12:10:01 +0200 From: "Michael S. Tsirkin" Message-ID: <20111114101001.GD16454@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC1792.3030004@codemonkey.ws> <4EBC4260.1090405@codemonkey.ws> <4EBCF5DA.1000605@redhat.com> <4EBE499E.4030100@redhat.com> <4EC0E638.8030908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC0E638.8030908@redhat.com> Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Lucas Meneghel Rodrigues , KVM mailing list , Juan Jose Quintela Carreira , "libvir-list@redhat.com" , Marcelo Tosatti , QEMU devel , Avi Kivity On Mon, Nov 14, 2011 at 10:58:16AM +0100, Kevin Wolf wrote: > Am 12.11.2011 11:25, schrieb Avi Kivity: > > On 11/11/2011 12:15 PM, Kevin Wolf wrote: > >> Am 10.11.2011 22:30, schrieb Anthony Liguori: > >>> Live migration with qcow2 or any other image format is just not going to work > >>> right now even with proper clustered storage. I think doing a block level flush > >>> cache interface and letting block devices decide how to do it is the best approach. > >> > >> I would really prefer reusing the existing open/close code. It means > >> less (duplicated) code, is existing code that is well tested and doesn't > >> make migration much of a special case. > >> > >> If you want to avoid reopening the file on the OS level, we can reopen > >> only the topmost layer (i.e. the format, but not the protocol) for now > >> and in 1.1 we can use bdrv_reopen(). > > > > Intuitively I dislike _reopen style interfaces. If the second open > > yields different results from the first, does it invalidate any > > computations in between? > > Not sure what results and what computation you mean, but let me clarify > a bit about bdrv_reopen: > > The main purpose of bdrv_reopen() is to change flags, for example toggle > O_SYNC during runtime in order to allow the guest to toggle WCE. This > doesn't necessarily mean a close()/open() sequence if there are other > means to change the flags, like fcntl() (or even using other protocols > than files). > > The idea here was to extend this to invalidate all caches if some > specific flag is set. As you don't change any other flag, this will > usually not be a reopen on a lower level. > > If we need to use open() though, and it fails (this is really the only > "different" result that comes to mind) then bdrv_reopen() would fail and > the old fd would stay in use. Migration would have to fail, but I don't > think this case is ever needed for reopening after migration. > > > What's wrong with just delaying the open? > > Nothing, except that with today's code it's harder to do. > > Kevin It seems cleaner, though, doesn't it? -- MST