* 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
