G'Day,
----- solar...@nedharvey.com wrote:
> > From: dtrace-discuss-boun...@opensolaris.org
> > [dtrace-discuss-boun...@opensolaris.org] On Behalf Of Martin
> > Mueller - Sun Germany SE [martin.muel...@sun.com]
> >
> > Have a look at the Dtrace Toolkit from Brendan Gregg. rwsnoop
> > should do what you are asking for on files
>
> This seemed very promising when I first saw it ... But it doesn't seem
> to capture NFS activity. I sit here and watch it, meanwhile start "dd
> if=/dev/zero of=junk.file" on some other machine, writing over NFS,
> and ... No result appears on the rwsnoop output. ;-(
>
> Any other suggestions?
>
rwsnoop traces syscalls, and would work from the client. On the server,
NFS is kernel-based and accesses files without syscalls.
Use the NFS providers, if available, since they are a stable interface. Eg
(NFSv3):
# dtrace -n 'nfsv3:::op-read-start,nfsv3:::op-write-start { @[probefunc,
# args[1]->noi_curpath] = count(); }'
If they aren't available, you can try the fsinfo provider - if available. Eg:
# dtrace -n 'fsinfo:::read,fsinfo:::write { @[probefunc, args[0]->fi_pathname]
# = count(); }'
If that isn't available, you can dig it out of the (unstable) fbt provider,
and maybe sdt. You could probe NFS functions, the filesystem, or VFS. eg,
VFS on Solaris:
# dtrace -n 'fbt::fop_read:entry,fbt::fop_write:entry { @[probefunc,
# stringof(args[0]->v_path)] = count(); }'
Brendan
--
Brendan Gregg, Fishworks http://blogs.sun.com/brendan
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
