Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.4.0
-
3
-
5686
Description
The per-ofd and per-export brw_stats are not maintained although the proc files still exist (see /proc/fs/lustre/obdfilter//brw_stats and /proc/fs/lustre/obdfilter//exports/*/brw_stats). Since filter_iobuf is now osd_iobuf, down one layer and without access to the export, it would be difficult to restore maintenance of these files.
The per-ofd brw_stats file could be replaced with a symlink to ../../osd-whatever/whoever/brw_stats (as in the patch for LU-2358) but there doesn't seem to be consensus that doing so is the Right Thing.
Attachments
Issue Links
- is related to
-
LU-3300 Restore missing proc information for LMT
-
- Open
-
Activity
Alex, do you think that adding and removing a symlink in the per-export directory is more complex than adding it for the whole device? Something like "../osd/exports/
{nid}/brw_stats" for each ofd export.
I agree that it is less critical than the main brw_stats, but I have no idea how much these files are used or not.
hm, just read more carefully.. symlinks to export per-ofd stats are trivial, but John's question was also about per-export brw_stats and I agree it won't be that trivial to maintain. Andreas, do you think we need to preserve per-export brw_stats?
I'm fine with few symlinks from obdfilter to osd. this is already proven to be clear and trivial to implement.
Alex, what do you think about symlinking the brw_stats from the old location in /proc/fs/lustre/obdfilter/*/brw_stats to osd?
My preference would be that we DO have the symlink, so that tools that monitor these stats can find them in the same place at least across a couple of releases, and eventually they can move to get the stats from osd-* once there are a few versions that have them there.
Moving forward, I'd prefer to break up brw_stats into separate stats files, or at least transform it into YAML that can be parsed more easily, since the ASCII art layout is a mess for parsing.
Landed for 2.4