On 12/08/2017 09:30 AM, Max Reitz wrote: > On 2017-12-05 01:48, John Snow wrote: >> >> >> 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. > > Well, yeah, I know we do. But I consider this counter-intuitive and if > something is counter-intuitive it's often a bug. > >> 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. > > Do we have bitmaps attached to BlockBackends? I sure hope not. > > We should not have any interface that requires the use of BlockBackends > by now. If we do, that's something that has to be fixed. > > Max >
I'm not sure what the right paradigm is anymore, then. A node is just a node, but something has to represent the "drive" as far as the device model sees it. I thought that *was* the BlockBackend, but is it not? --js