On Tue 11 Apr 2017 04:49:21 PM CEST, Kevin Wolf wrote: >> >>> (We could even get one more bit if we had a subcluster-flag, because I >> >>> guess we can always assume subclustered clusters to have OFLAG_COPIED >> >>> and be uncompressed. But still, three bits missing.) >> >> >> >> Why can we always assume OFLAG_COPIED? >> > >> > Because partially allocated clusters cannot be used with internal >> > snapshots, and that is what OFLAG_COPIED is for. >> >> Why can't they be used? > > Refcounts are on a cluster granularity, so you have to COW the whole > cluster at once. If you copied only a subcluster, you'd lose the > information where to find the other subclusters.
Individual subclusters don't have reference counts, OFLAG_COPIED would always be at the cluster level, but else I don't see the problem (see the reply that I just wrote to Eric). >> > It if it's a real discard you can just discard it (which is what we >> > do for compat=0.10 images anyway); but zero-writes will then have >> > to be come real writes, yes. >> >> Perhaps we can give up that bit for subclusters then, that would >> allow us to double their number. We would still have the zero flag at >> the cluster level. Opinions on this, anyone? > > No, making the backing file contents reappear is really bad, we don't > want that. I'm not talking about making the backing file contents reappear, but about writing zeroes instead of setting the zero flag. >> >> Then (3) is effectively the same as (2), just that the subcluster >> >> bitmaps are at the end of the L2 cluster, and not next to each >> >> entry. >> > >> > Exactly. But it's a difference in implementation, as you won't have >> > to worry about having changed the L2 table layout; maybe that's a >> > benefit. >> >> I'm not sure if that would simplify or complicate things, but it's >> worth considering. > > Note that 64k between an L2 entry and the corresponding bitmap is > enough to make an update not atomic any more. They need to be within > the same sector to get atomicity. Good point. Berto