i see. Thanks a lot for your explain. i have some further questions below, i will be appreciated if you have time to answer.
by "arbitrary number", can i understand it as the user can decide how many keys in the keybuf or something else? when the keybuf code try to refill itself, it continues scan following "last_scan" or it start over from the beginning? if try to scan all the existing keys per round, will it be very costly? Thanks, Sheng On Wed, Jul 10, 2013 at 7:02 PM, Kent Overstreet <[email protected]> wrote: > On Wed, Jul 10, 2013 at 05:14:49PM -0400, sheng qiu wrote: >> Hi Kent, >> >> i am sorry to bother you again. i am reading the movinggc.c, i am >> really interested in this piece of codes. So if i enable the copy_gc, >> this piece of codes will be active. My question is after the gc_moving >> confirmed the gc_moving_threshold, it began to scan the bkeys. i do >> not quite understand how you fill the moving_gc_keys, do you go >> through all the current btree nodes to find proper keys for migration >> (the bucket.used_sectors < threshold)? or you do incremental scans? > > Incremental scans - the keybuf code scans the btree until it has some > arbitrary number of keys in a red black tree; the copy gc code pulls > keys out of that one at a time to move them and the keybuf code refills > itself by scanning incrementally as needed. -- Sheng Qiu Texas A & M University Room 332B Wisenbaker email: [email protected] College Station, TX 77843-3259 -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
