Re: [PATCH] vfs: Add a trace point in the mark_inode_dirty function

Ingo Molnar
2009-11-20T10:52:05Z

* Christoph Hellwig <hch@infradead.org> wrote:

> Guys, I think both the inode number and name do have a use case. For
> file system developers observing the filesystem the inode number is
> very useful, and if you look at the ext4 tracing already in tree or
> the xfs tracing going in in the next window they use the inode number
> all over.
>
> Which btw brings up another good argument - to make the tracing really
> useful we need to have conventions. While the inode number seems to
> be a realtively easy one printing the device is more difficult. XFS
> just prints the raw major/minor to stay simple, ext4 has a complicated
> ad-hoc cache of device names, and this one just prints the superblock
> id string.

Agreed.

> Of course for a user the name is a lot more meaninful, but also
> relatively expensive to generate. Then again I'm not even sure how
> the last pathname component only here is all that useful - it can't be
> used to easily find the file.

That's not the main point though - the point is for app developers (and
users) being able to see 'oh, _that_ file it is, we need to fix that'.
In the context of a specific app, the last component filename carries
95% of the useful information.

Look at how PowerTOP does it, for a real-life usecase.

Ingo