similar to: what files are being used from a NFS server perspective

FYI, I posted a blog a few days ago about a DTrace provider for NFS that is currently in development: http://blogs.sun.com/roller/page/samf?entry=a_dtrace_provider_for_nfs Let''s discuss any questions, comments, etc. here. I also advertised this on nfs-discuss at opensolaris.org. Naturally, I would expect the discussion here to be more on the specifics of DTrace, and the

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

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

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

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

I have been using iosoop script (see http://www.opensolaris.org/os/community/dtrace/scripts/) written by Brendan Gregg to look at the IO operations of my application. When I was running my test-program on a UFS filesystem I could see both read and write operations like: UID PID D BLOCK SIZE COMM PATHNAME 203803 4436 R 6016592 16384 diskio <none> 203803 4436 W 3448432

Hi, I''m working on some performance analysis with our database and it seems that when the file system (UFS) is mounted with forcedirectio, the IO probe are not triggered when an I/O event occurs. Could you confirm that ? If so, why ? Seb -- This message posted from opensolaris.org

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

Hey, Do you guys think that is a good idea to have a manual page for each provider with a complete description of what probes are offered ? Found some already under 7D category: dtrace dtrace (7d) - DTrace dynamic tracing facility fasttrap fasttrap (7d) - DTrace user instruction tracing provider fbt fbt (7d) - DTrace function boundary tracing provider

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

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 ...

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

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

Using the following dtrace command, I can see who''s calling what with lots of +/- numbers: dtrace -n ''fbt:ip:ip_output:entry{@dbtypes[((mblk_t *)arg1)->b_datap->db_type,caller] = count();}'' ...the output is what I want but not how I want to see it. What I''d rather see is the function names associated with caller and for db_type to be output in hex.

Hi, Following "anonymous tracing" chapter, I wanna trace kmem_init(), but after reboot, I can''t get anything, why? Here is my short script kmem_init.d: #!/usr/sbin/dtrace -s fbt::kmem_init:entry { stack(); } then I just use: #dtrace -AFs kmem_init.d #reboot #dtrace -ae < got nothing here> Thanks, -Alex This message posted from opensolaris.org

Hello. I have a Solaris 11/11 x86 box (which I migrated from SolEx 11/10 a couple of weeks ago). Without no obvious reason (at least for me), after an uptime of 1 to 2 days (observed 3 times now) Solaris sets arc_no_grow to 1 and then never sets it back to 0. ARC is being shrunk to less than 1 GB -- needless to say that performance is terrible. There is not much load on this system. Memory

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

Hi all, I am trying to write a D script which would print ustack() for every program in the system receiving SIGSEGV. All the stacks printed in trap()/sigtoproc() context do not have meaningful symbols. The following solves the problem to some degree but I''d much rather have a self-contained D script. dtrace -w -n ''fbt:genunix:sigtoproc:entry/arg2 == 11/ {

We cannot run the zilstat utility (from http://www.richardelling.com/Home/scripts-and-programs-1/zilstat) on an Solaris 10 u9 / x86 installed according SUNWCreq (which is a core install) while it works fine on a similar config but installed with all packages (SUNWCXall) So we know it works in this environment but it seems we miss an essential package here. That causes the dtrace: failed to