On Thu, Oct 8, 2015 at 9:09 AM, 蔡毅 <cymengxiang@xxxxxxx> wrote: > > Dear developers, > > Recently I met some troubles when I read the Ceph’s source code and understand the architecture. > The details of problems are as followed. > > 1.In monitoring tools, they can collect much data when Ceph runs. I wonder what > kind of data the Ceph can provide (object data, PG data or other data?). Could the > Ceph provide every object’s data (e.g. The times the object is read or wrote > ,the latest time the object is used ,etc.) ,if Ceph could ,in source code ,where > could I find these details. I really want to know the monitoring data the Ceph > can provides and where they are in source code so that I could know how to use it > more efficiently. For example, I know the Ceph could provide the data of the > objects’ number per PG, the read and write bandwidth, but I couldn’t find how to > achieve these in source code. I'm not quite sure what you're asking here, but I think you'll want to look at the MPGStats.h message (in ceph/src/messages), and trace backwards through the OSD code (ceph/src/osd/) which creates them and then forwards through the monitor code (ceph/src/mon/OSDMonitor.cc) > > 2.From official documents, Ceph provides the cache tiering to improve > performance. But I couldn’t find more details to describe the cache tiering > like which kind of algorithm the cache agent uses. In the source code, where > could I find these? The cache tiering is part of the OSD. Look at the TierAgentState.h file and the parts of ReplicatedPG.cc which reference it. > > 3.In write process , there are two responses to client ,first is from journal and > second is occurred when object writes to real disk .so when I write a object to > Ceph using librbd, does not the write finish until the second response occurs and > what mean the first and second responses for clients? When a object writes to journal > but not to filestore (that is not to disk ), could I read this object? If I could, > where could I read this object? You get a response from the OSDs: 1) when the write operation is durable. 2) when the write operation is readable. The order these arrive in will depend on your OSD configuration (btrfs can send readable before durable; xfs always sends durable first; etc). If you get a "durable" response, any subsequent operations on that object will wait until that durable op is readable before completing. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
