From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eM1PZ-0000gn-7k for qemu-devel@nongnu.org; Mon, 04 Dec 2017 19:48:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eM1PY-0006NB-8o for qemu-devel@nongnu.org; Mon, 04 Dec 2017 19:48:37 -0500 References: <20171109141631.25688-1-vsementsov@virtuozzo.com> <8ade3dfe-ec27-a096-5d09-9e694f03935a@redhat.com> From: John Snow Message-ID: <6372bf9a-b80b-f4c7-33fa-88f35e3062db@redhat.com> Date: Mon, 4 Dec 2017 19:48:27 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] blockdev-backup: enable non-root nodes for backup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, qemu-block@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, armbru@redhat.com On 12/04/2017 05:21 PM, Max Reitz wrote: > On 2017-12-04 23:15, John Snow wrote: >> >> >> On 12/01/2017 02:41 PM, Max Reitz wrote: >>> ((By the way, I don't suppose that's how it should work... But I don't >>> suppose that we want propagation of dirtying towards the BDS roots, do >>> we? :-/)) >> >> I have never really satisfactorily explained to myself what bitmaps on >> intermediate notes truly represent or mean. >> >> The simple case is "This layer itself serviced a write request." >> >> If that information is not necessarily meaningful, I'm not sure that's a >> problem except in configuration. >> >> >> ...Now, if you wanted to talk about bitmaps that associate with a >> Backend instead of a Node... > > But it's not about bitmaps on intermediate nodes, quite the opposite. > It's about bitmaps on roots but write requests happening on intermediate > nodes. > Oh, I see what you're saying. It magically doesn't really change my opinion, by coincidence! > Say you have a node I and two filter nodes A and B using it (and they > are OK with shared writers). There is a dirty bitmap on A. > > Now when a write request goes through B, I will obviously have changed, > and because A and B are filters, so will A. But the dirty bitmap on A > will still be clean. > > My example was that when you run a mirror over A, you won't see dirtying > from B. So you can't e.g. add a throttle driver between a mirror job > and the node you want to mirror, because the dirty bitmap on the > throttle driver will not be affected by accesses to the actual node. > > Max > Well, in this case I would say that a root BDS is not really any different from an intermediate one and can't really know what's going on in the world outside. At least, I think that's how we model it right now -- we pretend that we can record the activity of an entire drive graph by putting the bitmap on the root-most node we can get a hold of and assuming that all writes are going to go through us. Clearly this is increasingly false the more we modularise the block graph. *uhm* I would say that a bitmap attached to a BlockBackend should behave in the way you say: writes to any children should change the bitmap here. bitmaps attached to nodes shouldn't worry about such things.