On Fri, Oct 13, 2017 at 2:32 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Fri, 13 Oct 2017, Gregory Farnum wrote: >> Moving on to the stuff actually written down: >> How comfortable are we with the size of the currently-deleting >> snapshots maps, for computation purposes? I don't have a good way of >> quantifying that cost but I'm definitely tempted to split the sets >> into >> newly_deleted_snaps (for *this epoch*) >> deleting_snaps (which are kept around until removed_snaps_lb_epoch) >> newly_purged_snaps (also for this epoch, which I think is how you have >> it written?) > > The code I have now has 2 sets: removed_snaps and purged_snaps. > purged_snapd was already there before; removed_snaps is the superset that > includes stuff not yet purged. (I made it a superset thinking that > the filter_snapc() thing on every op will be faster if it only has to > filter against a single set instead of 2 of them, and that matters more > than the memory.) No, what I mean is: * we know that computing the overlap of interval sets can be expensive * so we want to only compute overlaps of small sets * this is especially true if we're doing it on all outstanding operations in librados, within a single thread So we definitely don't want to repeat comparisons if we don't have to. And I suspect there will be occasional periods of intense snapshot deletion from admins where they remove a number large enough to cause trouble, and we don't want that to result in noticeably slower IO submission on the client-side! So we should have a separate set of snaps which were just added to the removed_snaps during this epoch, that librados and the OSD map processing can use in their normal-course-of-business scanning. -Greg -- 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
