Is there any way to collect object-level I/O access traces in Ceph?
Dear all, Does Ceph provide a way to collect object-level I/O access traces? Specifically, can we collect the traces to record how many times each object has been accessed (read, write, etc.) during a fixed period of time? Thanks! LW -- 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
Re: Is there any way to collect object-level I/O access traces in Ceph?
Hi Greg, Thanks for your reply. I found that in /var/log/ceph directory on each node, there are several log files in it, such as ceph-client.admin.log, ceph-mds.ceph-node1.log, etc., which log file should I look at? Maybe the ceph-mds.ceph-node1.log? Specifically, is there any keyword I can search in the log file to locate the object operations? Thanks! LW On Fri, Jan 16, 2015 at 4:21 PM, Gregory Farnum g...@gregs42.com wrote: On Fri, Jan 16, 2015 at 11:28 AM, Lipeng Wan lipengwa...@gmail.com wrote: Dear all, Does Ceph provide a way to collect object-level I/O access traces? Specifically, can we collect the traces to record how many times each object has been accessed (read, write, etc.) during a fixed period of time? I don't think we have any programmatic access, but depending on what you need it for you could enable messenger logging (or filestore logging, depending on what exactly you want) and count the references there. -Greg -- 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
Question about the test() function in CrushTester class
Hi guys, I am now trying to use crushtool.cc to test crush algorithm. First, I build a new crush map using crushtool.cc and all the devices have the maximum weight (0x1). Then I assign different weights to devices using the --weight option and run the test() function. It seems that during the execution of test() function, the crush map was not modified based on the new device weights I gave, which means the bucket selection was still based on the initial device weight rather than the weights I gave. Dose this make sense? L. Wan -- 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
question about the data structure of crush_map
Hi guys, I am reading the source code of ceph and trying to understand the data structure of crush_map. Now I am confused by the use of struct crush_bucket **buckets in function int crush_do_rule(...) in src/crush/mapper.c. It seems that the index of array map-buckets[] could be negative (see line 551, src/crush/mapper.c). I was wondering if anyone could explain why the index of this array can be negative and how those buckets were added into this array. Thanks. Best, L. Wan -- 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
Re: question about the data structure of crush_map
Hi Dong, Thanks for your reply. Then is it valid to access the memory space specified by that negative id? L Wan On Sun, Dec 1, 2013 at 10:31 PM, Dong Yuan yuandong1...@gmail.com wrote: If my memory serves me well, negative id means buckets (root, room, rack, cabinet, etc.), well positive means osds. On 2 December 2013 11:20, Lipeng Wan lipengwa...@gmail.com wrote: Hi guys, I am reading the source code of ceph and trying to understand the data structure of crush_map. Now I am confused by the use of struct crush_bucket **buckets in function int crush_do_rule(...) in src/crush/mapper.c. It seems that the index of array map-buckets[] could be negative (see line 551, src/crush/mapper.c). I was wondering if anyone could explain why the index of this array can be negative and how those buckets were added into this array. Thanks. Best, L. Wan -- 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 -- Dong Yuan Email:yuandong1...@gmail.com -- 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
