freebsd stable - Dec 2010 - DTrace (or other monitor) access to LBA of a block device

Hi,

do we have any way to monitor which LBAs of which block device are
read/written at a given time?

I stumbled upon this,
http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html

which is pretty intriguing. Unfortunately on FreeBSD we do not have
the DTrace io provider, so his dtrace script would not work.
Do we have another option to monitor block device access in a similar fashion?

Regards,
Riggs

On Thu, Dec 2, 2010 at 10:33 PM, Thomas Zander <
thomas.e.zander@googlemail.com> wrote:
> Hi,
>
> do we have any way to monitor which LBAs of which block device are
> read/written at a given time?
>
> I stumbled upon this,
> http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html
>
> which is pretty intriguing. Unfortunately on FreeBSD we do not have
> the DTrace io provider, so his dtrace script would not work.
> Do we have another option to monitor block device access in a similar
> fashion?
>
> Regards,
> Riggs
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
>

I'm happy FreeBSD user and not a developer but as far as I know (see:
http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html)
there is no such thing like block device in FreeBSD. It might be possible to
do what you want in other way or with different type of device.

Regards,
Mateusz Marzantowicz

On Thu, Dec 2, 2010 at 1:33 PM, Thomas Zander
<thomas.e.zander@googlemail.com> wrote:
> Hi,
>
> do we have any way to monitor which LBAs of which block device are
> read/written at a given time?
>
> I stumbled upon this,
> http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html
>
> which is pretty intriguing. Unfortunately on FreeBSD we do not have
> the DTrace io provider, so his dtrace script would not work.
> Do we have another option to monitor block device access in a similar
fashion?
GEOM sounds like a good candidate for probing of that kind.

sudo dtrace -n 'fbt:kernel:g_io_deliver:entry { printf("%s %d %d
%d\n",stringof(args[0]->bio_from->geom->name),
args[0]->bio_cmd,
args[0]->bio_offset, args[0]->bio_length); }'

Keep in mind that g_io_deliver will be called for each GEOM node from
top to bottom for each completed request. You may need to add some
filtering on device name to avoid redundant info.

--Artem

Quoting Andriy Gapon <avg@freebsd.org> (from Mon, 06 Dec 2010 18:08:26
+0200):
> on 06/12/2010 16:59 Alexander Leidinger said the following:
>> I do not think it is trivial. The amount of discussion around this  
>> does not makes
>> me want to do a MFC.
>
> Sorry, I must have missed the discussion.
> Could you please clarify what is not trivial in this case?
> The change itself seems to be just a few lines... Are there any
prerequisite
> changes, or some politics, or etc?
The few lines presented in this thread (the ctfmerge) should not be a  
problem, but the big patch I did resulted in comments that the ctf*  
stuff is not printed, that there are things regarding config which  
should be done differently (Warner has put them on his TODO list, as  
this is a generic problem and not directly related to my changes). For  
-current it was not a problem, and the changes during the pid-provider  
work included a little rework of the Makefile related stuff (as you  
may know). So just MFCing my changes is IMHO not enough.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
Love tells us many things that are not so.
		-- Krainian proverb