Piyush,
> Just to elaborate on "It never went anywhere" part, in case someone is
> interested in picking up the patch that Robert Gordon pointed to
> (http://cr.opensolaris.org/~danhua/webrev/onnv-clone.patch.).
>
> The prototype for the NFS v3 client provider was done by Danhua Shao. It
> was working and also went through a code review process on nfs-discuss
> alias. The provider and the probes were demonstrated to work as
> expected. The key issue in the current provider design is the use of
> tsd_set and tsd_get functions in order to get a handle on RPC xid where
> the probes get fired. The problem is that we need a reasonable way to
> harvest the RPC xid in the higher level nfs functions. As of now, the
> design uses tsd_set and tsd_get routines. I believe that there is high
> overhead associated with the use of these functions. At the time this
> work was done, we did not come out with a more appropriate approach to
> harvest RPC xid values.
at least from inspection of their implementation
(uts/common/disp/thread.c), the overhead doesn't seem so high except for
the case when tsd_set() is used for the first time on a thread. Obviously,
one would have to quantify the overhead and decide if this is deemed
acceptable for the observability gained.
> I am also attaching the written description of NFSv3 client provider
> specification, which was posted earlier on these email aliases when the
> work was being done actively.
Thanks. I'll have a look, but doubt that I'll be able to do anything soon:
too much on my plate right now.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
