Hi all, I tried to search but failed to find any information. But it seems when you trace different parts of IO and the underlying filesystem is vxfs it won''t show filesystemdetails (ie. filenames etc.). So how do you find out about the arguments that go with each probe? Since arg[2]->fi_name just shows "none" for instance. Am I just complicating things here, is there an easier way to go about this or do you have to read the sourcecode? Any answers is appreciated. thanks //Mike -- This message posted from opensolaris.org
I''m answering the first one myself since I actually found it by searching. So ''dtrace -v'' gives me a hint about the arguments. But as for my second question, I have still not been able to decode filesystem names, directories etc. when vxfs is involved. Has anyone out there been successful with dtracing vxfs? //Mike -- This message posted from opensolaris.org
Mikael Kjerrman wrote:> I''m answering the first one myself since I actually found it by > searching. So ''dtrace -v'' gives me a hint about the arguments. But as > for my second question, I have still not been able to decode filesystem > names, directories etc. when vxfs is involved. Has anyone out there been > successful with dtracing vxfs?IIRC someone once mentioned that that''s not possible with vxfs (I assume due to the way they compile their stuff). someone please correct me if that''s wrong. Michael -- Michael Schuster Sun Microsystems, Inc. recursion, n: see ''recursion''
On Thu, Sep 20, 2007 at 09:22:36AM -0700, michael schuster wrote:> Mikael Kjerrman wrote: > > I''m answering the first one myself since I actually found it by > > searching. So ''dtrace -v'' gives me a hint about the arguments. But as > > for my second question, I have still not been able to decode filesystem > > names, directories etc. when vxfs is involved. Has anyone out there been > > successful with dtracing vxfs? > > IIRC someone once mentioned that that''s not possible with vxfs (I assume > due to the way they compile their stuff).Fortunately, the only to _compile_ your stuff such to completely evade DTrace would be to either invent your own ABI or write your own kernel linker -- and you would probably need to do both. The only thing that I can think of that you might be making reference to is that on SPARC, our FBT instrumentation methodology (namely, branch insertion) requires that modules are no larger than the size of the branch displacement minus the size of the VA that we reserve for our trampoline. Upshot: we can''t instrument modules on SPARC that have more than 3MB of text. This is very rare, and (frankly) reflects dubious software engineering, but to see if you''re falling into this, run "size -f" on the kernel binary (e.g. "size -f /kernel/fs/vxfs"). And if you are running into this, you might want to ask Symantec why it''s taking them more than 3MB to do less than what ZFS does in ~400K... ;) - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Thanks for the input, this is what i get # /usr/ccs/bin/size -f /kernel/fs/sparcv9/vxfs 1437852(.text) + 2472(.rodata) + 1789(.rodata1) + 31608(.data) + 37861(.data1) + 352(.bss) = 1511934 # So I''m assuming I''m ok on that problem (Veritas states in their release notes that the vxio module is too big though). Still, if anyone has anymore information about tracing vxfs I''d appreciate it //Mike -- This message posted from opensolaris.org
Mikael Kjerrman wrote:> Thanks for the input, this is what i get[...] Mikael, can you please contact me directly? thx -- Michael Schuster Recursion, n.: see ''Recursion''
Hello Michael, Friday, September 21, 2007, 5:52:23 PM, you wrote: MS> Mikael Kjerrman wrote:>> Thanks for the input, this is what i getMS> [...] MS> Mikael, can you please contact me directly? MS> thx What''s the end result of this? -- Best regards, Robert Milkowski mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
Hi, turns out rwsnoop (included in the toolkit) is able to decode pathname in a vxfs filesystem. My problem now is that sometimes, that does not work as expected either. In some cases rwsnoop tells me there are reads and writes against files that does not exist. -- This message posted from opensolaris.org
G''Day Mikael, On Wed, Oct 24, 2007 at 02:30:50AM -0700, Mikael Kjerrman wrote:> Hi, > > turns out rwsnoop (included in the toolkit) is able to decode pathname in a vxfs filesystem. My problem now is that sometimes, that does not work as expected either. In some cases rwsnoop tells me there are reads and writes against files that does not exist.rwsnoop gets its pathname from the in-kernel vnode_t->v_path, which is a cached variable for observability/debugging. There are instances where it can become inaccurate, such as file renames, and there have been updates to improve this in recent versions of Solaris. Check bugs.opensolaris.org and do a text search for "v_path dtrace" (there are a number to check out). The code to rwsnoop, in case anyone is interested, is really showing its age - it was written for Solaris 10 3/05. These days it should use the fsinfo provider, or the fds[] array at least. cheers Brendan -- Brendan [CA, USA]