Project

General

Profile

Feature #48057

add debug information for client address

Added by Patrick Donnelly 3 months ago. Updated 3 months ago.

Status:
Fix Under Review
Priority:
High
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
Development
Tags:
Backport:
Reviewed:
Affected Versions:

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.

History

#1 Updated by Xiubo Li 3 months ago

  • Status changed from New to In Progress

#2 Updated by Jeff Layton 3 months 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().

#3 Updated by Patrick Donnelly 3 months 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?

#4 Updated by Xiubo Li 3 months 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 ?

#5 Updated by Patrick Donnelly 3 months 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.

#6 Updated by Xiubo Li 3 months 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.

#7 Updated by Xiubo Li 3 months 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.

@Jeff,

If you are okay with the debugfs approach, I will post the patch out later.

#8 Updated by Jeff Layton 3 months 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.

#9 Updated by Patrick Donnelly 3 months 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!

#10 Updated by Xiubo Li 3 months 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.

#11 Updated by Xiubo Li 3 months ago

  • Status changed from In Progress to Fix Under Review

Also available in: Atom PDF