On 06/03/2015 04:15 AM, Jan Schermer wrote:
Thanks for a very helpful answer. So if I understand it correctly then what I want (crash consistency with RPO>0) isn’t possible now in any way. If there is no ordering in RBD cache then ignoring barriers sounds like a very bad idea also.
Yes, that's why the default rbd cache configuration in hammer stays in writethrough mode until it sees a flush from the guest.
Any thoughts on ext4 with journal_async_commit? That should be safe in any circumstance, but it’s pretty hard to test that assumption…
It doesn't sound incredibly well-tested in general. It does something like what you want, allowing some data to be lost but theoretically
preventing fs corruption, but I wouldn't trust it without a lot of testing. It seems like db-specific options for controlling how much data they can lose may be best for your use case right now.
Is there someone running big database (OLTP) workloads on Ceph? What did you do to make them run? Out of box we are all limited to the same ~100 tqs/s (with 5ms write latency)…
There is a lot of work going on to improve performance, and latency in particular: http://pad.ceph.com/p/performance_weekly If you haven't seen them, Mark has a config optimized for latency at the end of this: http://nhm.ceph.com/Ceph_SSD_OSD_Performance.pdf Josh _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
