There is something that ZFS does well and is very clever way to treat this: when new data is written is is written to both the flash device AND to the RAM Memory. Then when it's the time to flush it to the permanent storage it reads that data from the RAM e not from the flash (why read from a slower device if you have a fast one available). So in this scenario if the flash devices fails you don't loose any data as it still exists in memory. The only possibility is when you have a power cut AND the flash device fails at the same time which is very unlikely. Therefore in my view there is only 1 justification to use a RAID-1 for writeback: if you don't want to loose write performance if the flash device fails until you are able to replace it. Fernando On 14/09/2017 12:04, Emmanuel Florac wrote: Le Thu, 14 Sep 2017 11:46:11 -0300 FERNANDO FREDIANI <fernando.frediani@xxxxxxx> écrivait: Not really mandatory but optional. >From bcache documentation: "In the event of a data IO error on the flash it will try to recover by reading from disk or invalidating cache entries. For unrecoverable errors (meta data or dirty data), caching is automatically disabled; if dirty data was present in the cache it first disables writeback caching and waits for all dirty data to be flushed." If the cache is dirty and has failed, your data is lost or corrupted all the same. The way a SSD fails is usually one second it works, the next second it's as dead as a rock. If you're using it as a write cache, whatever amount of data is dirty is lost. If it's 8 GB, you've lost your last 8 GB of writes, often very important filesystem metadata and/or database journal, i.e. your data is completely hosed. Don't use SSDs as write cache without RAID-1 (or use very expensive, redundant NVMe SSDs only), unless your data isn't very important. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
