Trapping Block I/O

Trapping Block I/O

[Block Device]

Hi,

    I need to trap _all_ the I/O going to each and every block device
in the system. I used jprobes to trap calls to generic_make_request.
Is this the correct/only place to do such a thing ?
Or do I have to monitor the q->make_request_fn for every device ?

Thanks & Regards
-BD.

Re: Trapping Block I/O

[Fawad Lateef]

On 9/23/05, Block Device <blockdevice@gmail.com> wrote:
>
>     I need to trap _all_ the I/O going to each and every block device
> in the system. I used jprobes to trap calls to generic_make_request.
> Is this the correct/only place to do such a thing ?
> Or do I have to monitor the q->make_request_fn for every device ?
>

Yes, generic_make_request or monitoring q->make_request_fn can trap
the _all_ I/O tpo block devices but other approach might be a little
bit odd/difficult but through that you can get every request to block
device .... the approach is you create a block device and then create
that block device as a wrapper on your device, now use your block
device and in its request function (can alter the data and sectors
etc) and calls generic_make_request for the original device on which
you created wrapper .... So by doing this you can easily monitor
requests (similar to this approach is used in LVM/RAID) ......


--
Fawad Lateef

Re: Trapping Block I/O

[Jens Axboe]

On Fri, Sep 23 2005, Fawad Lateef wrote:
> you created wrapper .... So by doing this you can easily monitor
> requests (similar to this approach is used in LVM/RAID) ......

Or just use btrace, pull it from:

git://brick.kernel.dk/data/git/blktrace.git

-- 
Jens Axboe

Re: Trapping Block I/O

[Fawad Lateef]

On 9/23/05, Jens Axboe <axboe@suse.de> wrote:
> On Fri, Sep 23 2005, Fawad Lateef wrote:
> > you created wrapper .... So by doing this you can easily monitor
> > requests (similar to this approach is used in LVM/RAID) ......
>
> Or just use btrace, pull it from:
>
> git://brick.kernel.dk/data/git/blktrace.git
>

Thnx for telling about btrace .... I havn't tried/looked at it before !!!!


--
Fawad Lateef

Re: Trapping Block I/O

[Jens Axboe]

On Fri, Sep 23 2005, Fawad Lateef wrote:
> On 9/23/05, Jens Axboe <axboe@suse.de> wrote:
> > On Fri, Sep 23 2005, Fawad Lateef wrote:
> > > you created wrapper .... So by doing this you can easily monitor
> > > requests (similar to this approach is used in LVM/RAID) ......
> >
> > Or just use btrace, pull it from:
> >
> > git://brick.kernel.dk/data/git/blktrace.git
> >
> 
> Thnx for telling about btrace .... I havn't tried/looked at it before !!!!

Well it's pretty new, so no wonder. But it should do everything you want
and lots more. There's a list for it here:

linux-btrace@vger.kernel.org

I'm a little pressed for time these days, but I'll do a proper announce
/ demo of all the features starting next week since it's basically
feature complete now.

If you don't use git, there are also snapshots available on kernel.org,
more precisely here:

kernel.org/pub/linux/kernel/people/axboe/blktrace/

but kernel.org is pretty slow these days, so pulling from the git repo
above is greatly recommended.

-- 
Jens Axboe

Re: Trapping Block I/O

[Fawad Lateef]

On 9/23/05, Jens Axboe <axboe@suse.de> wrote:
> Well it's pretty new, so no wonder. But it should do everything you want
> and lots more. There's a list for it here:
>
> linux-btrace@vger.kernel.org
>
> I'm a little pressed for time these days, but I'll do a proper announce
> / demo of all the features starting next week since it's basically
> feature complete now.
>
> If you don't use git, there are also snapshots available on kernel.org,
> more precisely here:
>
> kernel.org/pub/linux/kernel/people/axboe/blktrace/
>
> but kernel.org is pretty slow these days, so pulling from the git repo
> above is greatly recommended.
>

Ya, I looked at it and its looking very good tool to tracing block I/O
layer, but this tracing requires recompilation of the kernel and have
to use on kernel directly from kernel.org but its not a big deal, I
hope it will get into the main kernel soon ....

By the way my approach about creating wrapper and getting the device
requests without modification into the kernel and can be easily used
on any block device ...... ;)


--
Fawad Lateef

Re: Trapping Block I/O

[Jens Axboe]

On Fri, Sep 23 2005, Fawad Lateef wrote:
> On 9/23/05, Jens Axboe <axboe@suse.de> wrote:
> > Well it's pretty new, so no wonder. But it should do everything you want
> > and lots more. There's a list for it here:
> >
> > linux-btrace@vger.kernel.org
> >
> > I'm a little pressed for time these days, but I'll do a proper announce
> > / demo of all the features starting next week since it's basically
> > feature complete now.
> >
> > If you don't use git, there are also snapshots available on kernel.org,
> > more precisely here:
> >
> > kernel.org/pub/linux/kernel/people/axboe/blktrace/
> >
> > but kernel.org is pretty slow these days, so pulling from the git repo
> > above is greatly recommended.
> >
> 
> Ya, I looked at it and its looking very good tool to tracing block I/O
> layer, but this tracing requires recompilation of the kernel and have
> to use on kernel directly from kernel.org but its not a big deal, I
> hope it will get into the main kernel soon ....

That is true, I plan on submitting it for 2.6.15. The goal was to get
relayfs pushed in first and that did happen for 2.6.14.

> By the way my approach about creating wrapper and getting the device
> requests without modification into the kernel and can be easily used
> on any block device ...... ;)

There are certainly a lot of ways to get the data out to user space, by
far the bulk of the code is in the monitoring application. blktrace
should be pretty fast though, one of the goals was to make sure it would
be very light weight on the kernel side (which it is) and very fast on
getting the data out (also achieved, relayfs works very well). The
xprobe approach does have certain advantages, the main one being that
you can easily modify it.

-- 
Jens Axboe

Re: Trapping Block I/O

[Fawad Lateef]

On 9/23/05, Jens Axboe <axboe@suse.de> wrote:
> > Ya, I looked at it and its looking very good tool to tracing block I/O
> > layer, but this tracing requires recompilation of the kernel and have
> > to use on kernel directly from kernel.org but its not a big deal, I
> > hope it will get into the main kernel soon ....
>
> That is true, I plan on submitting it for 2.6.15. The goal was to get
> relayfs pushed in first and that did happen for 2.6.14.
>

That will be nice ....

>
> There are certainly a lot of ways to get the data out to user space, by
> far the bulk of the code is in the monitoring application. blktrace
> should be pretty fast though, one of the goals was to make sure it would
> be very light weight on the kernel side (which it is) and very fast on
> getting the data out (also achieved, relayfs works very well). The
> xprobe approach does have certain advantages, the main one being that
> you can easily modify it.
>

I will test/use it soon and will let you know if find any bug/problem :)


--
Fawad Lateef

Re: Trapping Block I/O

[Block Device]

The problem to creating a wrapper in the manner sugegsted is that
any filesystems mounted or other stuff which uses the original device
must be stopped
and changed to start using the new pseudo device. I want something
which can be as
non intrusive as possible. Am looking @ Jens btrace :) ..

Thanks &Regards
-BD


On 9/23/05, Fawad Lateef <fawadlateef@gmail.com> wrote:
> On 9/23/05, Block Device <blockdevice@gmail.com> wrote:
> >
> >     I need to trap _all_ the I/O going to each and every block device
> > in the system. I used jprobes to trap calls to generic_make_request.
> > Is this the correct/only place to do such a thing ?
> > Or do I have to monitor the q->make_request_fn for every device ?
> >
>
> Yes, generic_make_request or monitoring q->make_request_fn can trap
> the _all_ I/O tpo block devices but other approach might be a little
> bit odd/difficult but through that you can get every request to block
> device .... the approach is you create a block device and then create
> that block device as a wrapper on your device, now use your block
> device and in its request function (can alter the data and sectors
> etc) and calls generic_make_request for the original device on which
> you created wrapper .... So by doing this you can easily monitor
> requests (similar to this approach is used in LVM/RAID) ......
>
>
> --
> Fawad Lateef
>