Re: [RFC][PATCH] bcache: ver 3

From: Kent Overstreet
Date: Sat Apr 24 2010 - 16:08:49 EST


On 04/24/2010 07:47 AM, Egon Alter wrote:

I'm wondering if this is similar to the "Cleancache" patches send a few days
before.

Could bcache provide a (block-dev) backend to cleancache? Also there is fs-
cache (for networks-fs only currently). Can these caches be combined somehow?

Egon

I just looked at cleancache, and it looks like it's trying to solve part of the same problem at a different level - sort of giving the page cache a second level, instead of transparently making block devices faster. I didn't see any code for whatever holds pages when they're not in memory, I gather this was originally intended for VMs where pages in the l2 cache are still in memory, just not memory owned by the vm kernel.

Managing the cache itself is much simpler in that case; IMO most of the complexity involved in using an SSD as cache is the indexing, allocation, etc. - it's kind of like writing a filesystem, minus the notion of files, plus we can play fast and loose in certain ways.

That said, adding things to the cache should definitely be done more like the way cleancache does it; the page cache is what knows what's going on. So I don't think there's much if any code that could be shared, but definitely the hooks cleancache/ramzswap are using is what bcache should be using.

fs-cache is completely different, I haven't looked at it too much but just knowing its approach I don't think there's any way it'll be as efficient as bcache will be. It just makes more sense - makes things a lot simpler and there's less overhead involved in working with ranges of sectors than doing it at the filesystem level... and this way the allocation is determined entirely by bcache, and can be better optimized for ssd erase blocks. (Having the code run under generic_make_request does make the code more interesting since we can't sleep, but that's a solved issue and doesn't add to the work it does in the fast path).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/