My test on newstore show much poorer performance than filestore
Hi I have a try of the newstore to explore its performance, which shows its performance is much poorer than filestore. I test my cluster using fio, Here is the comparison of the two store with randread randwrite scenario: rw=randread, bs=4K, numjobs=1: newstore: bw=2280.7KB/s, iops=570 filestore: bw=4846.6KB/s, iops=1211 rw=randwrite, bs=4K, numjobs=1: newstore: bw=32999 B/s, iops=8 filestore: bw=250978 B/s, iops=61 The two tests are performed using the same hardware, but newstore is much poorer than filestore. From the view of the community, newstore is the next default backend store in Ceph, but why its performance so poor. Could someone tell me why? Thanks wenjunh -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OSD Crash for xattr _ absent issue.
Hi, Samuel Sage In our current production environment, there exists osd crash because of the inconsistence of data, when reading the “_” xattr. Which is described in the issue: http://tracker.ceph.com/issues/10117. And I also find a two year’s old issue, which also describes the same bug: http://tracker.ceph.com/issues/3676. I think there is a apparent flaw in the related code. Could you help to review my last comment describing the way to fix the bug. I prefer the second way, we just delete the object if we can’t get the “_” xattr, instead of crashing the osd, and the object has two other replicas, which can serve the client’s request. And when the next time self-healing process(scrub, deep scrub) occurs, the object can recover from its peer. Because I am not so proficient of the source code, I don’t know if the repairing way has any other side effects on the ceph cluster. If you have any idea about the bug, please feel free to let me know. Thanks Wenjunh -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
