I pressed "send" too early, here's the last part of my reply: On Fri 28 Jun 2019 02:57:56 PM CEST, Alberto Garcia wrote: >> I also ran some tests on a rotating HDD drive. Here having >> subclusters doesn't make a big difference regardless of whether there >> is a backing image or not, so we can ignore this scenario.
> Interesting, this is kind of unexpected. Why would avoided COW not > make a difference on rotating HDDs? (All of this is cache=none, > right?) The 32K/4K with no COW is obviously much faster (it's also faster with 1MB and 2MB clusters), it's the rest of the scenarios that show no improvement. >> === Changes to the on-disk format === >> >> In my original proposal I described 3 different alternatives for >> storing the subcluster bitmaps. I'm naming them here, but refer to >> that message for more details. >> >> (1) Storing the bitmap inside the 64-bit entry >> (2) Making L2 entries 128-bit wide. >> (3) Storing the bitmap somewhere else >> >> I used (1) for this implementation for simplicity, but I think (2) is >> probably the best one. > > Which would give us 32 bits for the subclusters, so you'd get 128k/4k > or 2M/64k. Or would you intend to use some of these 32 bits for > something different? No, 32 bits for subclusters, or 64 if we don't have the 'all zeroes' bit (we discussed this in a separate message). > I think (3) is the worst because it adds another kind of metadata > table that we have to consider for ordering updates. So it might come > with more frequent cache flushes. Yes I agree. Berto
