Thanks! Also note that you do not need to log every event, just register...and consequently try to scale down relay buffers, reducing the risk of
a mask of interesting ones to decrease the output logging rate. We could
so with some better setup for that though, but at least you should be
able to filter out some unwanted events.
memory constraints caused by blktrace activation.
Pretty pointless, unless you are tracing lots of disks. 4x128kb gone
wont be a showstopper for anyone.
Counters are also cheaper with regard to memory consumption. CountersHowever, a fast network connection plus a second system for blktraceIt's hard to make something that will suit everybody. Maintaining some
data processing are serious requirements. Think of servers secured
by firewalls. Reading some counters in debugfs, sysfs or whatever
might be more appropriate for some one who has noticed an unexpected
I/O slowdown and needs directions for further investigation.
counters in sysfs is of course less expensive when your POV is cpu
cycles.
are probably cause less side effects, but are less flexible than
full-blown traces.
And the counters are special cases and extremely inflexible.