Thanks, that’s it exactly. But I think that’s really too much work for now, that’s why I really would like to see a quick-win by using the local RBD cache for now - that would suffice for most workloads (not too many people run big databases on CEPH now, those who do must be aware of this). The issue is - and I have not yet seen an answer to that - would it be safe as it is now if the flushes were ignored (rbd cache = unsafe) or will it completely b0rk the filesystem when not flushed properly? Jan > On 01 Jun 2015, at 12:37, Nick Fisk <nick@xxxxxxxxxx> wrote: > > Hi Mark, I think the real problem is that even tuning Ceph to the Max it is still potentially 100x slower than a hardware raid card for doing these very important sync writes. Especially in DB's that have been designed to rely on the fact they can submit a large chain of very small IO's, without some sort of cache sitting at the front of the whole Ceph infrastructure (Journals and cache tiering are too far back), Ceph just doesn't provide the required latency. I know it would be really quite a large piece of work, but implementing some sort of distributed cache with a very low overhead that could plump direct into librbd would dramatically improve performance, especially in a lot of enterprise workloads. >> _______________________________________________ >> ceph-users mailing list >> ceph-users@xxxxxxxxxxxxxx >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |