Capturing I/O traces
ivoras at fer.hr
Tue Jan 9 14:43:44 UTC 2007
> Ivan Voras wrote:
>> Fluffles wrote:
>>> One thought that comes to mind is the gnop geom class; with verbose mode
>>> this provides a text log of all the I/O accesses. But it does not
>>> provide the exact time/concurrency etc, only the offset, length, I/O
>> What do you mean by "time" and "concurrency"? You do realize that
>> requests are serialized on the low level?
> Sure but simply capturing the serial order of requests might not be
> sufficient. For example: the application might 'wait' for one request to
> be finished because it needs that data in order to do another I/O
> request. I guess this is the hard part. If i would just execute the I/O
If an application has two threads (or there are two processes) making a
request at the same time, the lower level WILL get two requests, even if
the "first one" hasn't completed. This is nondeterministic - you can't
know which application's request will be the "first" and on the GEOM
level you don't know what application has made the request. It's all
anonymous I/O at that level, completed asynchronously.
Is this what you're asking or is it something else?
> I guess it's not easy to really make something like this be reliable and
> realistic, but i'd like to come as close as possible. For example, the
> website StorageReview also uses traces to benchmark specific uses, two
> I'd like to use traces of applications on FreeBSD (or GNU/Linux) to
> benchmark KDE startup, MySQL, Apache and other applications. So i can
> have benchmark suites like "desktop", "webserver" and "database". That
> would be very neat.
Nobody is questioning the use of I/O traces for benchmarking - I've seen
many utilities that do it.
Of course, raw I/O traces are only useful for benchmarking raw I/O -
more useful for most workloads would be VFS traces (because it involves
CPU, locking, etc...).
More information about the freebsd-geom