On Wed, Sep 21, 2011 at 08:42:01AM +0300, Pekka Enberg wrote: > On Wed, Sep 21, 2011 at 5:55 AM, Kent Overstreet > > <kent.overstreet@xxxxxxxxx> wrote: > >> Short version: bcache is for making IO faster. > > On Wed, Sep 21, 2011 at 8:33 AM, Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote: > > That's helpful... > > Your documentation isn't helpful either: > > +Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be > +nice if you could use them as cache... Hence bcache. > > So it's a cool hack but you fail to explain why someone wants to use > it. You also fail to explain why you decided to implement it the way > you did instead of making it more like fscache, for example. > > Really, why do I need to go digging for this sort of information? It > feels almost as if you don't want people to review your code... The documentation should be better and better organized to be sure, but I'm honestly not sure what's so strange about the concept of a cache for block devices.. My changelog messages are certainly lousy but they aren't really the place for a design doc, if that's what you're looking for. As for bcache's design vs. fscache's design... well, they're so unlike each other I'm not sure it even makes much sense to go into much. Bcache caches block devices, fscache caches at the filesystem layer. They each have uses where the other can't be used. If you want more than that - IMO bcache's design is simpler, higher performing, and more flexible. bcache doesn't have to have a notion of files; it caches extents. It can cache filesystem metadata - it can cache anything. Because bcache has its own superblock (much like md), it can guarantee that bcache devices are consistent; this is particularly important if you want to do writeback caching. You really don't want to accidently mount a filesystem that you were doing writeback caching on without the ache - bcache makes it impossible to do so accidently. Is any of that useful? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
