lkml.org 
[lkml]   [2009]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] vfs: Add a trace point in the mark_inode_dirty function

* 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


\
 
 \ /
  Last update: 2009-11-20 11:55    [W:0.336 / U:0.180 seconds]
©2003-2011 Jasper Spaans. Advertise on this site