On 2020/11/10 23:44, Ilya Dryomov wrote:
On Tue, Nov 10, 2020 at 3:19 PM <xiubli@xxxxxxxxxx> wrote:
From: Xiubo Li <xiubli@xxxxxxxxxx>
The logic is the same with osdc/Objecter.cc in ceph in user space.
URL: https://tracker.ceph.com/issues/48053
Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
---
V3:
- typo fixing about oring the _WRITE
include/linux/ceph/osd_client.h | 9 ++++++
net/ceph/debugfs.c | 13 ++++++++
net/ceph/osd_client.c | 56 +++++++++++++++++++++++++++++++++
3 files changed, 78 insertions(+)
diff --git a/include/linux/ceph/osd_client.h b/include/linux/ceph/osd_client.h
index 83fa08a06507..24301513b186 100644
--- a/include/linux/ceph/osd_client.h
+++ b/include/linux/ceph/osd_client.h
@@ -339,6 +339,13 @@ struct ceph_osd_backoff {
struct ceph_hobject_id *end;
};
+struct ceph_osd_metric {
+ struct percpu_counter op_ops;
+ struct percpu_counter op_rmw;
+ struct percpu_counter op_r;
+ struct percpu_counter op_w;
+};
OK, so only reads and writes are really needed. Why not expose them
through the existing metrics framework in fs/ceph? Wouldn't "fs top"
want to display them? Exposing latency information without exposing
overall counts seems rather weird to me anyway.
The fundamental problem is that debugfs output format is not stable.
The tracker mentions test_readahead -- updating some teuthology test
cases from time to time is not a big deal, but if a user facing tool
such as "fs top" starts relying on these, it would be bad.
Sorry, I am not sure whether had I replied this, I may missed this whole
thread.
As Patrick mentioned, the fs top won't rely on it, it will collect the
metrics from the MDS instead.
Thanks.
Thanks,
Ilya
