Re: PATCH 1/3] blktrace: support per-partition tracing

Ingo Molnar
2009-04-14T09:45:01Z

* Li Zefan <lizf@cn.fujitsu.com> wrote:

> >>> Lets note that this approach still has the (long existing)
> >>> limitation that only one device can be block-traced at a time.
> >>>
> >> No, both userspace blktrace and ftrace-plugin trace can trace
> >> more than one device at a time.
> >>
> >> # btrace /dev/sda /dev/dm-0
> >>
> >> or
> >>
> >> # echo 1 > /sys/block/sda/trace/enable
> >> # echo 1 > /sys/block/dm-0/trace/enable
> >
> > When they are independent - but not multiple partitions at a time:
>
> The only way to trace multipl partitions is to trace the whole
> sda, or set trace/start_lsa and trace/end_lsa properly.

... or, once we have the filtering engine upgraded, to use
or-connected filters:

# [mockup example]

sector >= 20000 && sector <= 30000
||
sector >= 50000 && sector <= 60000

Note that users dont have to care about these expressions - they
could get auto-added when tracing is enabled for a partition.

Such type of more complex compound filters are possible already -
what we dont have is comparison operators (right now we only have ==
and !=), nor built-in convenience support for dev_t.

Another variant would be:

dev == sda1
||
dev == sda3

type of compound filters - achieving the same goal as the sector
based filter.

> > [root@aldebaran ~]# echo 1 > /sys/block/sda/sda1/trace/enable
> > [root@aldebaran ~]# echo 1 > /sys/block/sda/sda2/trace/enable
> > -bash: echo: write error: Device or resource busy
>
> That's because struct blk_trace is attached to struct
> request_queue, sda1 and sda2 share the same rq:
>
> # echo 1 > /sys/block/sda/sda1/trace/enable
> # cat /sys/block/sda/sda1/trace/enable
> 1
> # cat /sys/block/sda/sda2/trace/enable
> 1

yes - i'm just pointing out the limitation. It's no big issue
currently - most of the actual tracing happens on specific
devices/partitions. (Perhaps 'whole system blk tracing' is a common
pattern though.)

I'm just pointing out that this is a beauty wart, and that it will
be mostly addressed when we go to TRACE_EVENT() based tracepoints in
blktrace :-)

Ingo