On 2020/8/19 21:41, Jeff Layton wrote:
On Wed, 2020-08-19 at 10:01 +0800, Xiubo Li wrote:
On 2020/8/19 4:10, Patrick Donnelly wrote:
On Tue, Aug 18, 2020 at 1:05 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
Bear in mind that if the same file has been opened several times, then
you'll get an increment for each.
Having an open file count (even for the same inode) and a count of
inodes opened sounds useful to me. The latter would require some kind
of refcounting for each inode? Maybe that's too expensive though.
For the second, yes, we need one percpu refcount, which can be add in
ceph_get_fmode() when increasing any entry of the
ci->i_nr_by_mode[fmode] for the first time, to decrease it in
ceph_put_fmode() when the ci->i_nr_by_mode[fmode] is empty. IMO, it
should be okay and won't cost too much.
Thanks
BRs
Sure.
To be clear, I'm not _really_ disputing the usefulness of these stats,
but I think if we're going to measure stuff like this, the changelog
needs to justify it in some way.
We may find in 2-3 years that some of these are not as useful as we
first thought, and if we don't have any of the original justification in
the changelog for it, it's harder to determine whether removing them is
ok.
This makes sense for me. Will add more details on the tracker and commit
comment later.
Thanks.
Would it potentially be more useful to report the number of inodes that
have open file descriptions associated with them? It's hard for me to
know as I'm not clear on the intended use-case for this.
Use-case is more information available via `fs top`.
