1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
**************************************************************************
* The following are notes for any script that uses the "fbt" provider.
* To identify these scripts, check the "STABILITY" section of the script's
* man page, or try grepping for "fbt" on the script.
*
* $Id: ALLfbt_notes.txt 44 2007-09-17 07:47:20Z brendan $
*
* COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
**************************************************************************
What is the "fbt" provider?...
* A DTrace library of probes that instruments raw kernel function calls.
* An "unstable" provider; meaning, scripts written using "fbt" are not
guarenteed to work on future versions of the OS - including after
patching the kernel.
In a perfect world...
* None of the DTraceToolkit scripts would use the "fbt" provider; instead
they would all use stable providers such as "proc", "sched", "io", etc.
* All the DTraceToolkit scripts would run on any system that supports DTrace.
In the real world...
* Not all stable providers exist yet. Many are in development, such as
stable networking providers.
* In the meantime, useful tools such as "tcpsnoop" and "tcptop" can
only be written using the unstable "fbt" provider (and these scripts have
broken several times due to kernel changes since they were first written).
* "fbt" provider based scripts,
- only run on a particular OS (eg, Solaris)
- may only run on a particular version of an OS (eg, Solaris 10 3/05)
- are likely to break for future OS releases (eg, Solaris 10 6/06)
* "fbt" provider based scripts also make the impossible possible, albiet
in a very unstable way, as a temporary solution while stable providers
are still in development.
* Once stable providers exist, "fbt" scripts can be rewritten to use them;
however these new scripts will only run on newer OS builds that support
the stable providers. (in other words, this won't help you if you remain
on Solaris 10 6/06; you'll need to upgrade, or survive with "fbt").
* Only some of the DTraceToolkit scripts use "fbt", and only a portion of
those have encountered stability issues - so this issue is limited.
The "fbt" provider exports raw kernel implementation, which isn't guarenteed
to be stable nor should it ever be (to do so would freeze kernel development
and bug fixes). The only practical solution is the development and
integration of stable providers (although that doesn't help people who keep
running older versions of the OS).
More harm than good?...
Is the inclusion of these "fbt" scripts more harm than good? Consider,
* the good,
- shows what is possible with DTrace
- should help a number of people solve specific performance issues,
on systems where they run
- a customer who really wants these scripts but on an OS version
where they don't work, have at least the source as a starting
point (and in some cases, the fix was trivial)
* the bad,
- teases and frustrates people who find these scripts don't work
on their OS
To minimise this issue, only a small number of "fbt" scripts have been
included, and they have been documented (see their man page) as unstable.
Can I help?...
If you really like an "fbt" based script and would like to keep using it
in a stable way, it may help to raise that with your vendor (Sun for Solaris,
Apple for MacOS). Sun has OpenSolaris forums, such as dtrace-discuss, which
are read by their engineers and the public.
|
