On Mon, 15 Jul 2013 13:57:39 -0400 DJ Delorie dj@redhat.com wrote:
I think this is a bad idea, at least for my setup. I really don't want my small expensive boot SSD being beaten to death trying to cache a multi-terabyte array, especially since I have plenty of RAM that already serves that purpose (the machine rarely reboots).
Actually, bcache is very good about *not* wearing out SSDs -- it writes in giant erase block-sized portions and likely you can tune how much is written.
And either of these layers must be turned on by an admin -- it's not going to be shoved down your throat.
At the very least, this feature should be disabled if the SSD is the boot/root drive. When SSDs fail, they fail completely, and it's irresponsible to cause early failure on a drive that's critical for booting and OS operation.
By default, bcache runs a write-through cache -- it only caches clean data. If the caching SSD dies, the bcache layer can just forward requests to spinning drive. No data is lost.
(Bcache has a writeback mode where data loss is possible. I do not recommend this mode.)
Also, I think such features should be postponed until/unless there's a clear and obvious way to configure/disable them that doesn't involve installing additional packages or editing obscure text files.
Again -- no one is forcing you to use this. It's opt-in.
Conrad