Dtrace as any other programming language has many details, and i was bitten by one of them…
Sometime ago i did a post about some strange values in the latency times provided by one script at NFSv3 provider wiki. Well, the culprit was the predicate, actually the predicate was not there… and surprise, was missed by the Brendan Gregg. If he can do a mistake in D, i’m fine with mine. ;-)
This time the problem was (again) strange values, actually the same in many tests. So, looking at the script execution, i did see:

dtrace: xxx dynamic variable drops

Seems not good…
So i did see a post from Bryan about a documentation about how to fix it. And looking my script, i did remember that when i did it, i had to put this:

#pragma D option dynvarsize=16m

But actually without to understand why… but did work, i did forget about it. Well, the script did not. ;-) The little error in the programming came alive again when the data was big enough, so to see it, i did just change the 16m to 256m. Everything was fine again. But now i had to fix it properly.
So i did start to look for the error, and is incredible how a simple script can be difficult to find a so simple mistake. I did forget to do a “must” in D thread-local variables:

“Always assign zero to thread-local variables that are no longer in use“.

Well, something simple like:

self->read = 0;

problem fixed. ;-)

But what i did not understand was how i could change the dynamic size to 16mb or 256mb without change the dtrace kernel parameter (16KB). I think i would need something like:

echo ‘dtrace_global_maxsize/Z F000000’ | mdb -kw

right? wrong? ;-)

ps.: I think Dtrace should exit on error when something like: dynamic variable drops. Bryan did write in the paper: “Must be eliminated for correct results“! Or there is some option in D for make such error more critical?

peace