Re: reverse link from bucket to keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux