<snip>
fbt:nfssrv:rfs4_findopenowner:entry
{
self->traceme = 1;
}
fbt:nfssrv:rfs4_dbsearch:entry
/self->traceme/
{
printf("%s %p ...", stringof(args[0]->dbi_keyname), args[1]);
}
fbt:nfssrv:rfs4_findopenowner:return
{
self->traceme = 0;
}
</snip>
cheers
-jan
Fascinating. The sources that I look at online
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs4_srv.c#7343)
... differ a little bit with the actual binaries (Since we run Sol 10 u8, and I
don't think I can see those sources anywhere).
But I managed to change it to:
printf("%s %s %p ...", stringof(args[0]->keyname),
stringof(args[0]->table->name),
args[1]);
and added to the "return" provider:
printf("%p", args[1]);
Which would presumably be equivalent to:
522 NFS4_DEBUG(table->debug & SEARCH_DEBUG,
523 (CE_NOTE, "Searching for key %p in table %s by %s",
524 key, table->name, idx->keyname));
and prints items like:
CPU ID FUNCTION:NAME
1 45602 rfs4_dbsearch:entry open_owner4 OpenOwner
fffffe88ff5cbe90 ...
1 45619 rfs4_findopenowner:return ffffffff9bbcd598
3 45602 rfs4_dbsearch:entry open_owner4 OpenOwner
fffffe88fd665090 ...
3 45619 rfs4_findopenowner:return ffffffff9bbcd9d8
which is pleasing. Not entirely sure what it means of course. I guess I need to
inspect the void *key to see what/who is actually looking up, but I can start
with running this and confirming that it does sometimes return NULL when we get
the troubles.
I don't think I realised just how powerful dtrace is.
--
Jorgen Lundman | <[email protected]>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
_______________________________________________
nfs-discuss mailing list
[email protected]
