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.023 / U:2.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site