On 03/29/2016 10:06 AM, Van Leeuwen, Robert wrote:
On 3/27/16, 9:59 AM, "Ric Wheeler" <rwheeler@xxxxxxxxxx> wrote:
On 03/16/2016 12:15 PM, Van Leeuwen, Robert wrote:
My understanding of how a writeback cache should work is that it should only take a few seconds for writes to be streamed onto the network and is focussed on resolving the speed issue of small sync writes. The writes would be bundled into larger writes that are not time sensitive.
So there is potential for a few seconds data loss but compared to the current trend of using ephemeral storage to solve this issue, it's a major improvement.
It think is a bit worse then just a few seconds of data:
As mentioned in the blueprint for ceph you would need some kind or ordered write-back cache that maintains checkpoints internally.
I am not that familiar with the internals of dm-cache but I do not think it guarantees any write order.
E.g. By default it will bypass the cache for sequential IO.
So I think it is very likely the “few seconds of data loss" in this case means the filesystem is corrupt and you could lose the whole thing.
At the very least you will need to run fsck on it and hope it can sort out all of the errors with minimal data loss.
I might be misunderstanding your point above, but dm-cache provides persistent
storage. It will be there when you reboot and look for data on that same box.
dm-cache is also power failure safe and tested to survive this kind of outage.
Correct, dm-cache is power-faillure safe assuming all hardware survives the reboot.
If you try to look at the rbd device under dm-cache from another host, of course
any data that was cached on the dm-cache layer will be missing since the
dm-cache device itself is local to the host you wrote the data from originally.
And here it can (and probably will) go horribly wrong.
If you miss the dm-cache device (cache/hypervisor failure) you will probably end up with an inconsistent filesystem.
This is because dm-cache is not a ordered write-back cache afaik.
I think that you are twisting in two unrelated points.
dm-cache does do proper ordering.
If you use it to cache writes and then take it effectively out of the picture
(i.e., never destage that data from cache), you end up with holes in a file system.
Nothing to do with ordering, all to do with having a write back cache enabled
and then chopping the write back cached data out of the picture.
This is no different than any other write cache, you need the write cache device
and the back end storage both to be present to see all of the data.
If you use dm-cache as a write through cache, this is not a problem (i.e., we
would only be used to cache reads).
Ric
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
