On Feb 7, 2014, at 2:07 PM, Kai Krakow <hurikhan77+bt...@gmail.com> wrote:
> Chris Murphy <li...@colorremedies.com> schrieb: > >>> If the database/virtual machine/whatever is crash safe, then the >>> atomic state that a snapshot grabs will be useful. >> >> How fast is this state fixed on disk from the time of the snapshot >> command? Loosely speaking. I'm curious if this is < 1 second; a few >> seconds; or possibly up to the 30 second default commit interval? And also >> if it's even related to the commit interval time at all? > > Such constructs can only be crash-safe if write-barriers are passed down > through the cow logic of btrfs to the storage layer. That won't probably > ever happen. Atomic and transactional updates cannot happen without write- > barriers or synchronous writes. To make it work, you need to design the > storage-layers from the ground up to work without write-barriers, like > having battery-backed write-caches, synchronous logical file-system layers > etc. Otherwise, database/vm/whatever transactional/atomic writes are just > having undefined status down at the lowest storage layer. This explanation makes sense. But I failed to qualify the "state fixed on disk". I'm not concerned about when bits actually arrive on disk. I'm wondering what state they describe. So assume no crash or power failure, and assume writes eventually make it onto the media without a problem. What I'm wondering is, what state of the subvolume I'm snapshotting do I end up with? Is there a delay and how long is it, or is it pretty much instant? The command completes really quickly even when the file system is actively being used, so the feedback is that the snapshot state is established very fast but I'm not sure what bearing that has in reality. Chris Murphy -- 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
