Feature #62364
open
support dumping rstats on a particular path
Added by Greg Farnum 9 months ago.
Updated 8 months ago.
Category:
Introspection/Control
Component(FS):
mgr/volumes
Description
Especially now that we have rstats disabled by default, we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
There are a few ways we could approach this — perhaps we add "fs" or "subvolume" commands to enable this, that just do a lookup on the mgr's built-in client? We could extend the cache dump options (which already let you dump a particular inode by number) to let you dump a particular path? Perhaps a brand new admin socket command on the MDS which does a full path walk lookup?
Greg Farnum wrote:
Especially now that we have rstats disabled by default,
When did this happen? Or, do you mean this in the context of snapshots (mds_snap_rstat - which is disabled by default)?
we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
`ceph.dir.rbytes` can be queried via getxattr. What am I misunderstanding? There was plan to use this in mgr/volumes to provide estimate of clone completion, but we dropped that since rbytes wasn't trustable for snapshots (but, is fine for head inodes).
Venky Shankar wrote:
Greg Farnum wrote:
Especially now that we have rstats disabled by default,
When did this happen? Or, do you mean this in the context of snapshots (mds_snap_rstat - which is disabled by default)?
I guess it would be more accurate to say “rbytes is disabled by default” —- the kernel clients aren’t showing it in normal ls output.
we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
`ceph.dir.rbytes` can be queried via getxattr. What am I misunderstanding? There was plan to use this in mgr/volumes to provide estimate of clone completion, but we dropped that since rbytes wasn't trustable for snapshots (but, is fine for head inodes).
The issue is that getxattr requires having an FS mount with access to that tool.
This is a supportability feature, not really new functionality.
Greg Farnum wrote:
Venky Shankar wrote:
Greg Farnum wrote:
Especially now that we have rstats disabled by default,
When did this happen? Or, do you mean this in the context of snapshots (mds_snap_rstat - which is disabled by default)?
I guess it would be more accurate to say “rbytes is disabled by default” —- the kernel clients aren’t showing it in normal ls output.
Ah, the `norbyytes` mount option.
we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
`ceph.dir.rbytes` can be queried via getxattr. What am I misunderstanding? There was plan to use this in mgr/volumes to provide estimate of clone completion, but we dropped that since rbytes wasn't trustable for snapshots (but, is fine for head inodes).
The issue is that getxattr requires having an FS mount with access to that tool.
This is a supportability feature, not really new functionality.
OK. So, `dump tree` would show various recursive stats and there is a `--depth` argument that probably can be used to limit the depth of dump. I'll need to check.
Venky Shankar wrote:
Greg Farnum wrote:
Venky Shankar wrote:
Greg Farnum wrote:
Especially now that we have rstats disabled by default,
When did this happen? Or, do you mean this in the context of snapshots (mds_snap_rstat - which is disabled by default)?
I guess it would be more accurate to say “rbytes is disabled by default” —- the kernel clients aren’t showing it in normal ls output.
Ah, the `norbyytes` mount option.
we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
`ceph.dir.rbytes` can be queried via getxattr. What am I misunderstanding? There was plan to use this in mgr/volumes to provide estimate of clone completion, but we dropped that since rbytes wasn't trustable for snapshots (but, is fine for head inodes).
The issue is that getxattr requires having an FS mount with access to that tool.
This is a supportability feature, not really new functionality.
OK. So, `dump tree` would show various recursive stats and there is a `--depth` argument that probably can be used to limit the depth of dump. I'll need to check.
`dump tree` gives up the required info, though, I think the `--depth` is a bit buggy.
Venky Shankar wrote:
Venky Shankar wrote:
Greg Farnum wrote:
Venky Shankar wrote:
Greg Farnum wrote:
Especially now that we have rstats disabled by default,
When did this happen? Or, do you mean this in the context of snapshots (mds_snap_rstat - which is disabled by default)?
I guess it would be more accurate to say “rbytes is disabled by default” —- the kernel clients aren’t showing it in normal ls output.
Ah, the `norbyytes` mount option.
we need an easy way to dump rstats (primarily rbytes, though not exclusively that) on given paths. This is really useful when monitoring things like deletion progress in a large directory, or tracking down problems — especially in mgr/volumes environments.
`ceph.dir.rbytes` can be queried via getxattr. What am I misunderstanding? There was plan to use this in mgr/volumes to provide estimate of clone completion, but we dropped that since rbytes wasn't trustable for snapshots (but, is fine for head inodes).
The issue is that getxattr requires having an FS mount with access to that tool.
This is a supportability feature, not really new functionality.
OK. So, `dump tree` would show various recursive stats and there is a `--depth` argument that probably can be used to limit the depth of dump. I'll need to check.
`dump tree` gives up the required info, though, I think the `--depth` is a bit buggy.
nvm my comment on --depth - it works as expected.
So,
ceph tell mds.a dump tree /filex846 | jq '.[].rstat'
{
"version": 0,
"rbytes": 0,
"rfiles": 1,
"rsubdirs": 0,
"rsnaps": 0,
"rctime": "0.000000"
}
Just that the inode needs to be in the MDS cache for it to dump the fields out.
Greg, nothing is required for this since the details are available as mentioned in the above note. Good to close?
Also available in: Atom
PDF