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

[Ingo Molnar]

* Christoph Hellwig <hch@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/