A bcache update
A bcache update
Posted May 14, 2012 20:10 UTC (Mon) by corbet (editor, #1)In reply to: A bcache update by blitzkrieg3
Parent article: A bcache update
Yes, exactly...as I tried to explain in that same paragraph. The data does exist on SSD, but it's only useful if the post-meteorite kernel knows what data is there. So the index and such have to be saved to the SSD along with the data.
Posted May 14, 2012 20:49 UTC (Mon)
by Lennie (subscriber, #49641)
[Link]
Eventually bcache is supposed to get support for mirroring the dirty data, so your dirty data will be stored on two SSDs before it is written to your already redundant backing store (like a RAID1 of HDDs).
Any data that is only a cached copy of data already written to the backing store will only be stored ones on one of the SSDs.
When that has been added that should take away most concerns people might have about their data.
Posted May 14, 2012 23:28 UTC (Mon)
by russell (guest, #10458)
[Link] (2 responses)
Posted May 15, 2012 7:56 UTC (Tue)
by Tobu (subscriber, #24111)
[Link] (1 responses)
Posted May 15, 2012 9:05 UTC (Tue)
by Lennie (subscriber, #49641)
[Link]
About how bcache will support more than one SSD in the future and how it will save 2 copies of your precious data on different SSDs instead of one:
bcache cache-sets
A bcache update
I think the SSD will be a single point of failure in writeback mode, because the underlying filesystem would have megabytes of metadata or journal blocks not written in the right order, which is bad corruption. I don't know how SSDs tend to fail; if they fail into a read-only the writes would still be recoverable in this case, as long as bcache can replay from a read-only SSD. Maybe a filesystem that handles SSD caching itself could avoid that risk.
A bcache update
A bcache update