Hi Kent, thanks for the explain above. my concern is that the GC_SECTORS_USED does not get you the correct valid data size within each bucket. for example, the GC_SECTORS_USED might return you larger than the bucket size, while when you go to match the reserved_sectors, you might get wrong. i do not know if you get my meaning. A simple way is run some test while enable the GC code, you will see how it work actually. If it's my misunderstanding, i am glad to hear from you later. Thanks, Sheng On Thu, Jul 11, 2013 at 10:10 PM, Kent Overstreet <kmo@xxxxxxxxxxxxx> wrote: > 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. -- Sheng Qiu Texas A & M University Room 332B Wisenbaker email: herbert1984106@xxxxxxxxx College Station, TX 77843-3259 -- 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
