[dm-devel] dm-cache failure semantics in write-back mode

[Thanos Makatos]

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 at shiftmail.org> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20150305/4047d7e9/attachment.htm>