I like the simplicity of this approach a lot. When the system isn't fragmented, this should work excellently. However when it is fragmented, this falls back to the current situation. Nevertheless in a heavily fragmented environment the onode size might be the least important problem to solve, so I agree this is the approach we should take. Sent from my iPhone. Please excuse all typos and autocorrect > On Aug 26, 2016, at 1:52 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > > Hi Allen, > > The "blobs must be confined to a extent map shard" rule is still somewhat > unsatisfying to me. There's another easy possibility, though: we > allow blobs to span extent map shards, and when they do, we stuff them > directly in the onode. The number of such blobs will always be small > (no more than the number of extent map shards), so I don't think size is a > concern. And we'll always already have them loaded up when we bring any > particular shard in, so we don't need to worry about any additional > complexity around paging them in. And we avoid the slightly annoying cut > points on compressed extents when they cross such boundaries. > > This also avoids some of the tuning practicalities that were annoying me > (does a global config option control where the enforced cut points are? > what happens if that changes on an existing store?) > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
