Man, this is a frustrating issue :) I haven't been able to come up with a way of fixing it right without rewriting a bunch of code. I do have a workaround figured out though if this is a real issue for you - it'll just increase internal fragmentation in the btree a bit, but with large btree nodes like you normally want not enough to matter. Though like I said, as long as your workload isn't 100% reads this shouldn't be an isuse. On Mon, Oct 1, 2012 at 4:00 PM, Kent Overstreet <koverstreet@xxxxxxxxxx> wrote: > On Mon, Oct 01, 2012 at 10:26:43PM +0000, Brad Walker wrote: >> Kent Overstreet <koverstreet@...> writes: >> >> >> > I was just browsing around the code, and I bet I know what it is - >> > btree_insert_check_key() is failing because the btree node is full. >> > >> > But, we should confirm this really is what's going on... Can you apply >> > this patch and rerun to test my theory? See if the number of times the >> > printk fires lines up with the number of cache misses. >> > >> >> >> I applied this change and I see a LOT of the messages. >> >> And the rate seems to be increasing. > > Sweet, we know what it is then. > > So, like I mentioned this won't be an issue on any workload with mixed > read/writes, so if that's what your production workloads are then this > may not matter to you. > > For warming up the cache, doing a few random writes (just enough that > you hit all the btree nodes - and there aren't many btree nodes, cat > internel/btree_nodes) will fix it. > > A real fix for this shouldn't be too hard, but it's not exactly trivial > and it'll be a pain to test... not quite sure when I'll get to it, but > it would be good to have it fixed. -- 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
