Ahh, I see I missed the critical bit at the top of the page - thanks for triggering me to look at it again. For posterity...
Cheers,
~Blairo
So the writeback mode in librbd and Qemu (at least for SCSI drives) passes on FUA/flush commands, i.e., an fdatasync etc. inside the guest will cause relevant blocks in the cache to be flushed, so if the guest thinks the data has been written then it has (at least as far as librbd/Qemu can guarantee).
On 7 February 2014 19:11, Alexandre DERUMIER <aderumier@xxxxxxxxx> wrote:
-- >>This page reads "If you set rbd_cache=true, you must set cache=writeback or risk data loss." ...Because if you don't set writeback in qemu, qemu don't send flush requests.
And if you enable rbd cache, and your host is crashing, you'll lost datas and possible corrupt the filesystem.
if you enable writeback,guest send flush request. If the host is crashing, you'll lost datas but it'll not corrupt the guest filesystem.
Presumably that depends on the filesystem in question. But I think the principle stands, with librbd writeback cache mode you might lose data due to host crash, but no more data than you would --expect-- to lose. E.g., if you're running a transactional database it'll typically be sync-ing to an intent/transaction log on write operations, that sync-ing (with the right filesystem under it) will cause any volatile DB data in the cache to be flushed.
Cheers,
~Blairo
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
