Chris Murphy <li...@colorremedies.com> schrieb: > I think most of these questions are better suited for the bcache list.
Ah yes, you are true. I will repost the non-btrfs related questions to the bcache list. But actually I am most interested in using bcache together btrfs, so getting a general picture of its current state in this combination would be nice - and so these questions may be partially appropriate here. > I > think there are still many uncertainties about the behavior of SSDs during > power failures when they aren't explicitly designed with power failure > protection in mind. At best I'd hope for a rollback involving data loss, > but hopefully not a corrupt file system. I'd rather lose the last minute > of data supposedly written to the drive, than have to do a fuil restore > from backup. These thought are actually quite interesting. So you are saying that data may not be fully written to SSD although the kernel thinks so? This is probably very dangerous. The bcache module could not ensure coherence between its backing devices and its own contents - and data loss will occur and probably destroy important file system structures. I understand your words as "data may only partially being written". This, of course, may happen to HDDs as well. But usually a file system works with transactions so the last incomplete transaction can simply be thrown away. I hope bcache implements the same architecture. But what does it mean for the stacked write-back architecture? As I understand, bcache may use write-through for sequential writes, but write-back for random writes. In this case, part of the data may have hit the backing device, other data does only exist in the bcache. If that last transaction is not closed due to power-loss, and then thrown away, we have part of the transaction already written to the backing device that the filesystem does not know of after resume. I'd appreciate some thoughts about it but this topic is probably also best moved over to the bcache list. Thanks, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
