similar to: DTrace provider for NFS

Hiya, I''m trying to track down some throughput latency that our customer seems to be attributing to our product, I can''t see what he''s talking about, but I want to try and get some deeper granularity than I might get with something like smokeping, and maybe even see if its down to something tunable on our end. I''ve been looking for some examples on how

We recently had a strange NFS performance anomaly between a V880 running snv_124 and two NetApp filers. To investigate, a DTrace NFSv4 (and eventually NFSv3) client provider would been extremely helpful. Unfortunately, all I could find were a request for code review of a v3 client provider and another request for help developing a v4 provider. Nothing seems to have come from those initiatives,

Hi all, I have questions about something I observed just now: 1) on AMD64, S10u1: # dtrace -n ''fbt::copystr:entry{printf ("%p\n", args[0]);}'' -c /bin/pwd dtrace: invalid probe specifier fbt::copystr:entry{printf ("%p\n", args[0]);}: in action list: index 0 is out of range for fbt::copystr:entry args[ ] but # dtrace -n ''fbt::copystr:entry{printf

Hi i''m trying to write my first dtrace script apparently i bit off a bit more than i can chew, i want to track io over sockets, i found your socketsize.d that gave me how to track writes, but i''m at a loss how to track reads, frankly i don''t see how your write tracker works because it uses a probe in a function that only takes two arguments but you grab size of write

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

OK, I''ve been fritzing around with something I noticed last night, thinking that I understood what was going on, but now it''s getting confusing again. A system that has been running for a couple of months had a hole in the probe ID list near the end in the middle of the fbt probes. And then a couple of syscall probes were stuck in the hole. It looked like this: ... 40311

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

If I use a simple dtrace script such as this: fbt::somefunc:entry{self->trace=1;} fbt::somefunc:return{self->trace=0;} fbt:::entry{} fbt:::return{printf("%lx", arg1);} then it will descend to whatever depth is necessary If I want to limit it to say 3 functions deep, how can I do that? The quick answer I want to use is to do "self->depth++" on each entry and then

Hi. I would like to print out a field of a vnode, but the argument to the function is of type vnode_t **. If I set "this->vpp" to arg2 in an entry function to zfs_lookup(), I''d like to retrieve the value of one of the fields of *(this->vpp) in the return function. Something like the below (but the syntax below is not right): printf("zfs_lookup:

I''m curious to know what files are being used from a NFS server perspective. I''m unable to trace the client because it is in the boot phase. Looking at the io provider, I believe it does not allow you to look at what files are being requested. That would lead me to the fbt provider. Does anyone know what fbt provides the file handle for NFS client request on the NFS

Hi, I know how to trace the number of bytes read/written by a program by summing the argument of that read/write syscall. However, the way the OS services read/write calls is in blocks. I wonder if it''s possible to trace the actual number of blocks read/written caused by the syscalls? -- This message posted from opensolaris.org

i''m using the following probe to calculate how many bytes are being written by tcp write calls, by process and total: fbt:ip:tcp_output:entry { this->tcpout_size = msgdsize(args[1]); @tcpout_size[execname] = sum(this->tcpout_size); @tcpout_size["TOTAL_TCP_OUT"] = sum(this->tcpout_size); } I run this probe for N seconds. I suppose that if i get the

Is there a list anywhere of the DTrace FBT provider calls for each version of Solaris since the Nevada build that hosed the DTrace Toolkit. I have no issue with rewriting what I need, but I am hoping to stave off having to look at all the source code to find everything. I know there is a new provider under development, but I need to be able to program DTrace routines for all the updates in

Hi All: In Solaris Dtrace User Guide, page 218, it says, "Functions that do not create a stack frame on x86 systems cannot be instrumented by FBT." Then what are these functions? What characteristics do they have? Regards TJ

Is there a trick to listing available providers? I can''t find it.

Referring to the DTrace manual: "Module If this probe corresponds to a specific program location, the name of the module in which the probe is located. This name is either the name of a kernel module or the name of a user library. Function If this probe corresponds to a specific program location, the name of the program function in which the probe is located." and then ...

Hello all, I saw this question about a year back in the archive[1], but with no final answer. I would like to trace shmget calls and also get the id of the shared memory segment. That script looked like[2], but we dont get the id since arg1 is the errno value. How do i access the shm id, i would need this to debug a customer problem but i don''t have time to learn it the hard

Hi All, One of the customer is seeing the following error messages. He is using a S10U1 system with all latest patches. Dtrace script is attached. I am not seeing these error messages on S10U2 system. What could be the problem? Thanks, Gangadhar. ------------------------------------------------------------------------ rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d dtrace:

Is there any work on keeping DTraceTools up to date with the latest snv builds. These scripts are pretty useful and help get a novice dtrace user like me doing useful work quickly. Specifically the tcp stack tools like tcptop and tcpsnoop don''t work with later OpenSolaris builds. Thanks, Gary -- This message posted from opensolaris.org

I have a number of systems running solaris10 and i see the package and binary for dtrace installed however whenever we try to run anything we get this error dtrace: failed to initialize dtrace: DTrace device not available on system the only system in which i dont have this error is the development server that has the full solaris 10 install while others are minimized, do i need additional