Thanks for clarifying this. My concern is that an "application writer" can be a Windows VM via qemu and I don't know if flush requests are supported in the specific qemu version we're using, I'm in the process of confirming that.
On Tue, Mar 3, 2015 at 9:58 PM, Spelic <spelic@xxxxxxxxxxxxx> wrote:
On 03/03/2015 18:13, Thanos Makatos wrote:
Thanks, Joe. So just to make sure I've understood correctly, if the SSD cache is configured as a write-back cache but the device cache is disabled/set to write-though on the HDD and the SSD, then there is no risk of data loss in the event of a failure. Is my understanding correct?
You don't seem to understand the semantics of flush.
Writes on filesystems and databases are made more or less like a copy-on-write semantic:
- New data is written elsewhere
- a flush is issued
- when flush returns you are sure that such new data is on stable storage (disk platters or similar)
- change one pointer to point from old data to new data (so small that this change is atomic)
- flush again
when this flush returns you are sure that the data on-disk is updated.
Now you understand why dm-cache has the semantics that it has, which is the same semantics as DRAM caches on HDDs.
Applications writers have to follow the semantics described above, in order to have "atomic" updates on disk. This is true with dm-cache but also with DRAM caches on HDDs.
Partial data losses are irrelevant if the above logic is followed.
S.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
