Hi folks,
While playing around with the FBT provider I came across something I simply
can''t figure out how to do.
I would really like to track I/O to some of our zvols - for writes something
like this does the trick :
dtrace -qn ''fbt:zfs:zvol_log_write:entry { @[args[0]->zv_name] =
count(); }'';
For reads this proves more difficult since the zvol_state struct (which holds
the zvol name) is not passed as an argument.
I haven''t used C since school (more than a decade ago) so excuse me for
mistaking but
judging from the zvol_read function in
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zvol.c
uses a pointer to the zvol_state struct instead.
How can I get my hands on that data from dtrace ?
/HenrikJ
--
This message posted from opensolaris.org
On Tue, Mar 2, 2010 at 3:20 AM, Henrik Johansen <fisaf at hotmail.com> wrote:> Hi folks, > > While playing around with the FBT provider I came across something I simply can''t figure out how to do. > > I would really like to track I/O to some of our zvols - for writes something like this does the trick : > > dtrace -qn ''fbt:zfs:zvol_log_write:entry { @[args[0]->zv_name] = count(); }''; > > For reads this proves more difficult since the zvol_state struct (which holds the zvol name) is not passed as an argument. > > I haven''t used C since school (more than a decade ago) so excuse me for mistaking but > judging from the zvol_read function in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zvol.c uses a pointer to the zvol_state struct instead. > > How can I get my hands on that data from dtrace ?zvol_read() gets the pointer to the zvol_state struct by caling ddi_get_soft_state(). You can get this pointer by tracing ddi_get_soft_state() predicated on being called from inside zvol_read(). For example, you could do something like this: fbt::zvol:read:entry { self->trace = 1; } fbt::ddi_get_soft_state:return / self->trace / { self->zv = args[1]; } fbt::zvol_read:return / self->zv / { @[self->zv->zv_name] = count(); self->zv = 0; self->trace = 0; } Chad
> On Tue, Mar 2, 2010 at 3:20 AM, Henrik Johansen > <fisaf at hotmail.com> wrote: > > Hi folks, > > > > While playing around with the FBT provider I came > across something I simply can''t figure out how to do. > > > > I would really like to track I/O to some of our > zvols - for writes something like this does the trick > : > > > > dtrace -qn ''fbt:zfs:zvol_log_write:entry { > @[args[0]->zv_name] = count(); }''; > > > > For reads this proves more difficult since the > zvol_state struct (which holds the zvol name) is not > passed as an argument. > > > > I haven''t used C since school (more than a decade > ago) so excuse me for mistaking but > > judging from the zvol_read function in > http://src.opensolaris.org/source/xref/onnv/onnv-gate/ > usr/src/uts/common/fs/zfs/zvol.c uses a pointer to > the zvol_state struct instead. > > > > How can I get my hands on that data from dtrace ? > > zvol_read() gets the pointer to the zvol_state struct > by caling > ddi_get_soft_state(). You can get this pointer by > tracing > ddi_get_soft_state() predicated on being called from > inside > zvol_read(). > > For example, you could do something like this: > > fbt::zvol:read:entry > { > self->trace = 1; > bt::ddi_get_soft_state:return > / self->trace / > { > self->zv = args[1]; > bt::zvol_read:return > / self->zv / > { > @[self->zv->zv_name] = count(); > self->zv = 0; > self->trace = 0; > > ChadThanks Chad. Here is what I ended up with : fbt::zvol_read:entry { self->trace = 1; } fbt::ddi_get_soft_state:return / self->trace / { self->zv = (zvol_state_t *)args[1]; } fbt::zvol_read:return / self->zv / { @[self->zv->zv_name] = count(); self->zv = 0; self->trace = 0; But this return what appears to be a hexdump as well as the zvol names and their read counts [....] 370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 3a0: 00 f0 6a 5d 11 ff ff ff 00 d0 ef 62 11 ff ff ff ..j].......b.... [...] 2 tank/intern01_lun_02 3 I can figure out where that comes from ... /HenrikJ -- This message posted from opensolaris.org
On Wed, Mar 3, 2010 at 2:31 AM, Henrik Johansen <fisaf at hotmail.com> wrote:> > > But this return what appears to be a hexdump as well as the zvol names and their read counts > > ? ? ? [....] > ? ? ? 370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................ > ? ? ? 380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................ > ? ? ? 390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................ > ? ? ? 3a0: 00 f0 6a 5d 11 ff ff ff 00 d0 ef 62 11 ff ff ff ?..j].......b.... > ? ? ? [...] > ? ? ? ? ? ? ? ?2 > ?tank/intern01_lun_02 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?3 > > I can figure out where that comes from ... >I haven''t had much time to look at this. I''ve tried reproducing the problem, but I can''t with the simple test I''m running. But what''s happening with the hex dump you''re seeing is that DTrace is trying to print something that it thinks should be a string but which contains unprintable characters. For this case, it defaults to a hex dump. What that means is that zv_name contains garbage. I''m not sure why this would be happening. Chad