[dtrace-discuss] DTrace instead of `lsof`?

[Brendan Gregg]

G'Day Boyd,

On Fri, 18 Aug 2006, Boyd Adamson wrote:

> On 16/08/2006, at 1:35 AM, Brendan Gregg wrote:
> > A while back I did write a Perl/procfs lsof-like tool for Solaris 10,
> > http://www.brendangregg.com/Solaris/lsfd - but it's not terribly
> > exciting,
> > and the path it uses (the cached vnode path) isn't 100% accurate.
>
> As a kind of mental ECC, are you saying this because the paths are
> cached at open time and the files may have been renamed or unlinked
> since then?

Yes. Another issue is:

 $ grep brendan /usr/bin/w

 # dtrace -n 'fbt::fop_read:entry /execname == "grep"/ {
     trace(stringof(args[0]->v_path)); }'
 dtrace: description 'fbt::fop_read:entry ' matched 1 probe
 CPU     ID                    FUNCTION:NAME
   0  16173                   fop_read:entry   /usr/sbin/ipf
   0  16173                   fop_read:entry   /usr/sbin/ipf

Why is grep reading ipf?. Of course, it is technically correct - ipf has
the same inode as w (it's that wrapper), so it really is reading this
file. But not via that pathname.

We'd need to cache the path for each file descriptor in uf_entry_t
as well (which is only 64 bytes to start with). I'm not sure the
overheads incured will be allowed, on the basis it makes us DTrace
people happier. The cached vnode path is correct, so long as we
remember what it is.

Brenadn