lkml.org 
[lkml]   [2009]   [Nov]   [12]   [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

* Kok, Auke <auke-jan.h.kok@intel.com> wrote:

> If you already know what the file object is, sure. We're interested in
> the case where we have no clue what the file object actually is to
> begin with. Having a trace with a random inode number pop up and then
> disappear into thin air won't help much at all, especially if we can't
> map it back to something "real" on disk. in time.

Yep.

It's similar to PID/comm tracing, which we already do consistently for
all major task events such as fork/exit, sleep/wakeup/context-switch,
etc.

By the 'use inode numbers' argument it should be perfectly fine to only
trace the physical PID itself, and look up the comm later in /proc, or
to add a syscall to do it.

In reality it's not fine. Not just the unnecessary overhead (you have to
look up something you already had) - but also that tasks will exit in
high-freq workloads (so the comm is lost), the PID might not match up
anymore, tasks can change their comm, etc.

The most important principle with event logging is that we want the most
high quality information and we want to a trustable and simple data
source: so for tasks we want the PID and the comm, and for files we want
the top name component and perhaps also the inode number (plus a
filesystem id), captured when the event happened.

Ingo


\
 
 \ /
  Last update: 2009-11-12 08:25    [W:0.110 / U:1.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site