similar to: DTrace provider proposal: COMSTAR iSCSI target port provider probes

The earlier post with the Dtrace probes definition (sent on April 23) was only to solicit feedback from all prospective users of iSCSI DTrace probes. I will follow up shortly with an updated document requesting approval from the community. thanks Priya -------- Original Message -------- Subject: Dtrace provider for the COMSTAR iscsi Target Port Provider - Review Request Date: Thu, 23 Apr

The iscsit_dtrace_draftv5.txt describes the Dtrace probes definition for the COMSTAR iSCSI target port provider. For all those interested in iSCSI, please take a look and send me your feedback/questions/suggestions etc by Thursday, April 20, 2009 thanks Priya -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iscsit_dtrace_draftv5.txt URL:

I have added a specification of probes for the fibre channel COMSTAR port provider to the DTrace section of wikis.sun.com. The proposal may be found here: http://wikis.sun.com/display/DTrace/fibre+channel+Provider I welcome feedback regarding this proposal. Thanks, Sam

I want to list/use the nfs probes but I get the error "dtrace: failed to match nfs*:::: No probe matches description". Is there a way to enable nfs provider probes? My system is running snv_112 (bfu''ed from the gate archive) # dtrace -lP nfs* ID PROVIDER MODULE FUNCTION NAME dtrace: failed to match nfs*:::: No probe matches

Hi, WARNING: Long post ahead I have an issue when starting multipathd. The kernel complains about "blk_cloned_rq_check_limits: over max segments limit". The server in question is configured for KVM hosting. It boots via iBFT to an iSCSI volume. Target is COMSTAR and underlying that is a ZFS volume (100GB). The server also has two infiniband cards providing four (4) more paths over SRP

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

I apologize if this has been covered before. I have not seen a blow-by-blow installation guide for Ubuntu onto an iSCSI target. The install guides I have seen assume that you can make a target visible to all, which is a problem if you want multiple iSCSI installations on the same COMSTAR target. During install Ubuntu generates three random initiators and you have to deal with them to get things

Hi, This is a proposal for probes for NFS v3 client(see attachment). These probes are under a new DTrace provider: nfsv3client. These new probes support tracing NFS v3 client activities such as sending RPC requests to NFS v3 server and receiving RPC replies from NFS v3 server. Formats and arguments of these new probes are quite similar to existing NFS v3 probes on server side (provider: nfsv3).

Hi, I have mentioned before that we have added some sdt dtrace probes in SAX, our APL interpreter. Encouraged by Angelo and Jignesh, I have created a small document (5 pages) describing our experience with it, together with some problems we have encountered and some scripts we use for pretty-printing dtrace outputs. The said document can be found at

I've integrated some DTrace [1] probes into R. Namely a probe which fires on fuction entry and return and one which fires before / after a garbage collection. Is there any interest in merging something like this into R-devel? If yes, I'd like to discuss which probes and what data would be useful / interesting from a developers standpoint. Greetings from Dortmund, Olaf Mersmann [1]

I am currently working on adding DTrace probes we have for Memcached 1.2.5 to the new binary protocol in 1.3 branch. The problem I am facing is that I should have had a new variable into the probe. When we added the probes, all memcached keys would be zeroterminated ascii strings, but in the binary protocol it may not be zero-terminated. So what do I do? According to

Author: ahl Repository: /hg/zfs-crypto/gate Revision: b1ab97f77b0ad2a4fe2a43d9c5aac7259840bb90 Log message: 6370454 dtrace should support USDT probes in static functions Files: update: usr/src/lib/libdtrace/common/dt_dof.c update: usr/src/lib/libdtrace/common/dt_link.c update: usr/src/lib/libdtrace/common/dt_provider.c update: usr/src/lib/libdtrace/common/dt_provider.h

Hello all, I am running an OpenSolaris server running 06/09. I installed comstar and enabled it. I have an ESXi 4.0 server connecting to Comstar via iscsi on its own switch. (There are two esxi servers), both of which do this regardless of whether one is on or off. The error I see is on esxi "Lost connectivity to storage device naa.600144f030bc450000004a9806980003. Path vmhba33:C0:T0:L0 is

Hi, I have a zfs volume that''s exported via iscsi for my wife''s Mac to use for Time Machine. I''ve just built a new machine to house my "big" pool, and installed build 129 on it. I''d like to start using COMSTAR for exporting the iscsi targets, rather than the older iscsi infrastructure. I''ve seen quite a few tutorials on how to use

Hi, I am fairly new to DTrace, and wanted to ask something regarding synchronization objects. I have a multithreaded C++ program in which I use semaphores (POSIX version) for synchronization. I was interested in using DTrace to figure out the total time for which each thread in my application sleeps, blocked on a semaphore, i.e., as a result of sem_wait() call. In order to measure this, I

Hi, As I''ve discussed before whenever we add USDT probes to a C++ function and call dtrace -l we get the mangled C++ name for the dtrace function, being listed :( Now the point of USDT probes is to abstract a higher level semantic construct for users to make use of. Surely it is not meant to be listing Unstable Interfaces (implementation details), such as the containing C++

hi folks we''re in final approach with Brendan''s work on the TCP and UDP providers, which have been discussed here previously in the context of the overall networking provider plan at: http://hub.opensolaris.org/bin/view/Community+Group+dtrace/NetworkProvider The specs have been updated to reflect recent changes and are available for review here:

Does anyone out there have any thoughts on the type of load common DTrace scripts would cause on a system if run 24x7? I know "common DTrace scripts" and their underlining probe calls a vague statement. So for the lack of a common and establish set of scripts in the OS, I''ll use the most popular right for my question...the DTraceToolkit from Brendan Gregg. Which by the

Hi, I am adding DTrace probes within NFS v3 client. In my current implementation, I use some tsd_*() functions and kmem_zalloc() function. These functions might be heavy and affect the performance. I want to call this function only when DTrace is running or the DTrace probes are enable. So is there a way to check DTrace is running or DTrace probe is enabled? Regards, Danhua

DTrace folks, I''m pleased to introduce a potential new DTrace-sponsored project: the Erlang DTrace provider. To be good OpenSolaris citizens, we want to put the formation of this officially sponsored project to a vote -- as outlined in the OpenSolaris Constitution -- so here are the details for the new Project, as prepared by the Project Team: Name : Erlang DTrace Integration