Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Perhaps I'm not understanding everything.
But it seems to me, that you could move the bcache functionality into the filesystem.
i.e. Why can't btrfs store all writes on that faster medium and them replicate them back to the slower one?
Also, isn't this akin to storing the journal of a filesystem externally (I've never done it). i.e. Why not point the ext3/ext4 journal at the SSD?
Would you get the same (or better) benefit?
It seem bcache is useful is the underlying filesystem doesn't do it, but in the above two cases, is there much benefit?
Bcache: Caching beyond just RAM
Posted Jul 9, 2010 1:21 UTC (Fri) by koverstreet (subscriber, #4296)
The main thing is the allocation strategy you want for caching is _completely_ different than for filesystems. Fragmentation isn't a real problem in the cache, since we can free fixed sized chunks regardless of what's in them. This means we're free to write data to the cache however we want to get the best performance. A filesystem has to retain data for an arbitrary amount of time, and thus needs to pay a lot of attention to making sure free space doesn't fragment too much.
Putting an external journal on an SSD gets you a bit of what bcache is after, but it'll only help with writes, and not to the extent bcache can. How would you effectively use an 80 gb journal? With bcache, you'll be able to fill up your caches with almost all dirty writes, and then write them out to your RAID6 with no restrictions on ordering - potentially turning a huge portion of random writes into mostly sequential ones, and even more will get overwritten in the cache before the raid ever sees them.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds