dtrace discuss - Feb 2008 - Is this still a limitation in DTrace?

The Release notes for Veritas Storage Foundation state that the reason you
cannot do fbt tracing of their vxio driver is because it''s text size is
larger than 2 MB:

Dynamic Tracing Function Boundary Tracing probes
Dynamic Tracing (DTrace) Function Boundary Tracing (FBT) probes are not
supported with the vxio driver. This is because of a limitation in Solaris 10
that
such probes cannot handle modules with a text size larger than 2MB. The
following error message is generated on the console as a result of using DTrace
FBT probes with the vxio driver:
fbt: WARNING: couldn?t allocate FBT table for module vxio
These messages are harmless, and can be safely ignored.

Here''s the size we come up with for the module:

# /usr/ccs/bin/size -f /kernel/drv/sparcv9/vxio
2915048(.text) + 64696(.rodata) + 241920(.rodata1) + 99120(.data) +
79624(.data1) + 6728(.bss) = 3407136

Is there a fix or workaround in the works for this?  We''re looking to
use vxio fbt probes but obviously can''t until this is resolved.  Asking
Symantec to lower the size of their text area is a non-starter.

Gordon Marler
gmarler at gmarler.com


--
This message posted from opensolaris.org

On Thu, Feb 28, 2008 at 08:51:12AM -0800, Gordon Marler
wrote:
> The Release notes for Veritas Storage Foundation state that the reason you
cannot do fbt tracing of their vxio driver is because it''s text size is
larger than 2 MB:
> 
> Dynamic Tracing Function Boundary Tracing probes
> Dynamic Tracing (DTrace) Function Boundary Tracing (FBT) probes are not
> supported with the vxio driver. This is because of a limitation in Solaris
10 that
> such probes cannot handle modules with a text size larger than 2MB. The
> following error message is generated on the console as a result of using
DTrace
> FBT probes with the vxio driver:
> fbt: WARNING: couldn?t allocate FBT table for module vxio
> These messages are harmless, and can be safely ignored.
> 
> Here''s the size we come up with for the module:
> 
> # /usr/ccs/bin/size -f /kernel/drv/sparcv9/vxio
> 2915048(.text) + 64696(.rodata) + 241920(.rodata1) + 99120(.data) +
79624(.data1) + 6728(.bss) = 3407136
> 
> Is there a fix or workaround in the works for this?  We''re looking
to use vxio fbt probes but obviously can''t until this is resolved. 
Asking Symantec to lower the size of their text area is a non-starter.
It''s only an issue on SPARC, not on x86.  And there is very little
chance
that modules greater than 2MB are going to be instrumentable by DTrace:
the limitation is a limitation in the instruction set architecture (branch
displacements are a signed 4MB quantity).  When one is talking about
modules that are greater than 2MB on SPARC, one is essentially talking only
about vxio -- and I think it''s safe to say that Sun is not about to
bear
an inordinate cost simply to be able to instrument a module that we feel
is obviated by ZFS. ;)

And should Symantec wish to sponsor the work, we would encourage them to
instead break up their absurdly large module.  (Note that this module
is larger than the kernel itself -- there''s really no excuse for that
much kernel text.)

Not that I have any opinions on this, of course... ;)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

and I think it''s safe to say that Sun
> is not about to bear
> an inordinate cost simply to be able to instrument a
> module that we feel
> is obviated by ZFS. ;)
> 
I was afraid someone would say that - unfortunately, until ZFS is fitted with
all of the bells and whistles that the combination of VxVM/VxFS has - true
sync/async replication with data ordering, intimate integration of snapshots
with NetBackup, and so on, we''ll continue running VxVM/VxFS on our
couple thousand Solaris systems.  Just pragmatic...
> And should Symantec wish to sponsor the work, we
> would encourage them to
> instead break up their absurdly large module.  (Note
> that this module
> is larger than the kernel itself -- there''s really no
> excuse for that
> much kernel text.)
> 
I wonder who, or which group at Symantec would be a good contact point for such
an effort...
> Not that I have any opinions on this, of course... ;)
> 
That''s ok - you can afford to ;>

Thanks for explaining the issue clearly.
> 	- Bryan
> --------------------
> Bryan Cantrill, Sun Microsystems Fishworks.
>       http://blogs.sun.com/bmc
> _________________________________________

--
This message posted from opensolaris.org

hi gordon,

i work for symantec and just came across this posting - interestingly enough,
when someone on my team ran into what i suspect was the same issue !
i''m from the file system side of the house. will reach out to the VxVM
folks to try and get this resolved.

btw, did you try and contact anyone from VxVM ? 

--
tyt


--
This message posted from opensolaris.org

this is fixed in 5.0MP3 onwards. The size of the vxvm driver is reduced to
handle the dtrace limitation of not going up above 2MB driver size.
--
This message posted from opensolaris.org