On Thu, Jul 11, 2013 at 11:02:01AM -0400, sheng qiu wrote: > Hi Kent, > > i think i get a little clear about your codes. so initially each newly > allocated buckets are SET_GC_SECTORS_USED(bucket.size), then during > the btree gc, you update the bucket by accumulate the still valid key > data. So if the bucket has more valid data left, it should be > accumulated more for each round at the btree gc. I think this is fine. > But at the movinggc code, when you calculate how many sectors to move > for each bucket, you directly add the current GC_SECTORS_USED(bucket), > which is actually the accumulated value (relative value), not the > actual valid size of data within the bucket. Is this correct? I guess > that's why i ended up with the threshold equal to newly allocated > bucket size. That "sectors_to_move" we're calculating isn't for any one bucket, it's how many _total_ sectors we're going to move this iteration. The reason is we've got a fixed size reserve of buckets that can be allocated for moving gc - we may not be able to allocate more than that. But when we start copying data out of buckets, we always want to copy out of the buckets that had the least amount of live data in them. So we take our heap of buckets with the smallest GC_SECTORS_USED(), and pop buckets off the top until sectors_to_move is under our reserve - that is, until we've got few enough buckets that we know we'll be able to move all the data in them. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
