From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UziRZ-0007Rd-Nr for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:16:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UziRW-00026v-Ux for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:16:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UziRW-00026i-Mi for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:16:02 -0400 Date: Thu, 18 Jul 2013 15:15:52 +0800 From: Fam Zheng Message-ID: <20130718071552.GI29052@T430s.nay.redhat.com> References: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> <51E6A8D3.4050406@redhat.com> <20130717152149.GN2458@dhcp-200-207.str.redhat.com> <51E752B9.7030502@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51E752B9.7030502@linux.vnet.ibm.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd Reply-To: famz@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Kevin Wolf , pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dietmar@proxmox.com On Thu, 07/18 10:28, Wenchao Xia wrote: > =E4=BA=8E 2013-7-17 23:21, Kevin Wolf =E5=86=99=E9=81=93: > >Am 17.07.2013 um 16:23 hat Eric Blake geschrieben: > >>On 07/17/2013 08:03 AM, Wenchao Xia wrote: > >>>This series allow user to read internal snapshot's contents without = qemu-img > >>>convert. Another purpose is that, when qemu is online and have taken= an > >>>internal snapshot, let user invoke qemu-nbd to do any thing on it ex= cept write. > >>> > >>>This brings two interesting issues: > >>>1 is it safe to let qemu-nbd and qemu access that file at same time? > >> > >>Probably not, for the same reason we tell people to not use qemu-img > >>while qemu is active on a file. > > > >No, it's not. There's the built-in NBD server, but making internal > >snapshots usable with it would require some non-trivial changes in the > >block layer and the qcow2 code. > > > What changes should be done? I think currently, it is safe except > resizing/snapshot delete, those operation can be forbidded when nbd > is running. >=20 For external NBD to a export an in use image the answer should be "don't do it", with the same reasons as above. For internal NBD server, I agree with Stefan's reply: a read-only BlockDriverState that is dependent on the guest's used one, and share in-memory data for consistency. > >>>I think it is safe, since qemu-nbd is read only. The data will be co= rrect from > >>>qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is run= ning, and > >>>data is flushed to storage after qemu take that snapshot so that qem= u-nbd > >>>would see the correct data. > >> > >>You're making assumptions that qemu won't be touching any metadata in= a > >>manner in which the read-only qemu-nbd could get confused; I'm not su= re > >>we are ready to make that guarantee. I think the export has to be fr= om > >>the running qemu process itself, rather than from a second process. > > > >I think a while ago I convinced myself that in practice it does work, > >but it's not a guarantee we're making and I won't hesitate to break th= e > >assumption if it's helpful for some feature. > > > I think it can be listed out about the features that may break the > assumption, if added later, then simply forbid nbd running at that case > by user. >=20 > This related to qcow2's specification: Do we allow another > process read an snapshot of one image while it is used, in normal > condition? It would be nice to have it as a storage software. But I don't think it's something that a format specification could achieve, i.e. it is not the right place to specify "how to synchronize multiple reader/writers to me", we can't do it by adding whatever bits to format itself. The question is similar to: we can't guarantee the consistency of data, no matter how advanced and sophisticated its structure is, unless we use lock to harmonize multiple users, which is totally orthogonal to the data itself. Thanks. --=20 Fam