Feature #48057
closedadd debug information for client address
Added by Patrick Donnelly over 3 years ago. Updated about 3 years ago.
0%
Description
The ceph-fuse client has a "status" asok command that provides: "inst", "addr", "inst_str", and "addr_str". The "addr_str" is used by qa to check if a the mount is blocklisted:
https://github.com/ceph/ceph/blob/8a2f2d82f49df1d5a94e97328f8b04a783d159d5/qa/tasks/cephfs/fuse_mount.py#L489
https://github.com/ceph/ceph/blob/8a2f2d82f49df1d5a94e97328f8b04a783d159d5/qa/tasks/cephfs/fuse_mount.py#L205
It would be the "ipaddr:port/nonce" format. The kernel client currently on provides its global id in the "mds_sessions" debug file. It would be useful it it also provided the ipaddr:port/nonce information as well.
Updated by Jeff Layton over 3 years ago
Given that the idea is to fetch this info for a particular mount, it may be best to implement this as a new ioctl().
Updated by Patrick Donnelly over 3 years ago
Jeff Layton wrote:
Given that the idea is to fetch this info for a particular mount, it may be best to implement this as a new ioctl().
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
Updated by Xiubo Li over 3 years ago
Patrick Donnelly wrote:
Jeff Layton wrote:
Given that the idea is to fetch this info for a particular mount, it may be best to implement this as a new ioctl().
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
I am not sure how widely will the /sys/debug files be enabled. Will it be possible that it will be disabled in some cases ?
Updated by Patrick Donnelly over 3 years ago
Xiubo Li wrote:
Patrick Donnelly wrote:
Jeff Layton wrote:
Given that the idea is to fetch this info for a particular mount, it may be best to implement this as a new ioctl().
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
I am not sure how widely will the /sys/debug files be enabled. Will it be possible that it will be disabled in some cases ?
Maybe. I suppose one reason to make an ioctl is that the operator may want to blacklist the client but they can get that information from the MDS session dump.
I think the only users of this information will be our upstream testing.
Updated by Xiubo Li over 3 years ago
Patrick Donnelly wrote:
Xiubo Li wrote:
Patrick Donnelly wrote:
Jeff Layton wrote:
Given that the idea is to fetch this info for a particular mount, it may be best to implement this as a new ioctl().
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
I am not sure how widely will the /sys/debug files be enabled. Will it be possible that it will be disabled in some cases ?
Maybe. I suppose one reason to make an ioctl is that the operator may want to blacklist the client but they can get that information from the MDS session dump.
I am not sure I get it here, the blocklisted info could be easily got from the fsc struct and most of the others we needed.
I think the only users of this information will be our upstream testing.
Yeah, if so the debugfs should be okay, I couldn't forsee what the benefit will the ioctl could give us.
Updated by Xiubo Li over 3 years ago
Have finished it in the debugfs, it will be like:
# cat /sys/kernel/debug/ceph/5d8facd7-6511-4205-8e73-a51e8772156e.client4657/status
status:
inst_str: client.4657 (0)10.72.37.120:0/3836002633
blocklisted: false
For the others, like the mdsmap/osdmap/monmap epochs we can get them from other existing debug files.
If you are okay with the debugfs approach, I will post the patch out later.
Updated by Jeff Layton over 3 years ago
Patrick Donnelly wrote:
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
They are organized by clientid, and it's not immediately obvious which clientid is mounted where. If I have a dozen cephfs mounts, then there is not currently a way to reliably match up a mountpoint with its clientid directory under /sys.
That may be a better solution actually -- stick this in /sys like you're planning, but also add a ioctl that allows you to get the clientid for a particular mount.
Updated by Patrick Donnelly over 3 years ago
Jeff Layton wrote:
Patrick Donnelly wrote:
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
They are organized by clientid, and it's not immediately obvious which clientid is mounted where. If I have a dozen cephfs mounts, then there is not currently a way to reliably match up a mountpoint with its clientid directory under /sys.
That may be a better solution actually -- stick this in /sys like you're planning, but also add a ioctl that allows you to get the clientid for a particular mount.
+1!
Updated by Xiubo Li over 3 years ago
Jeff Layton wrote:
Patrick Donnelly wrote:
Are not the /sys/debug files organized by mount? Why would we prefer ioctl to adding information to the /sys debug files?
They are organized by clientid, and it's not immediately obvious which clientid is mounted where. If I have a dozen cephfs mounts, then there is not currently a way to reliably match up a mountpoint with its clientid directory under /sys.
That may be a better solution actually -- stick this in /sys like you're planning, but also add a ioctl that allows you to get the clientid for a particular mount.
Sounds cool.
Have raised on separate tracker to follow this, please see https://tracker.ceph.com/issues/48124.
Updated by Xiubo Li over 3 years ago
- Status changed from In Progress to Fix Under Review
Updated by Xiubo Li about 3 years ago
- Status changed from Fix Under Review to Resolved