path: root/btreplay/Makefile
diff options
authorAlan D. Brunelle <>2007-10-02 12:35:07 -0400
committerJens Axboe <>2007-10-02 19:51:18 +0200
commitd47a3fec3f4bbcf6b0c6ef757a4eb449dd81d10a (patch)
treec23a7df0ca04c624a5d291d5ab4a96ff29a5a015 /btreplay/Makefile
parent4f93192893f41acfe1ded673c1111142b8f4cddd (diff)
Add btrecord/btreplay capability
These facilities allow one to attempt to replay a stream of IOs captured with blktrace. The general workflow is: 1. Initiate blktrace to capture traces 2. Do whatever to generate initial IO stream... 3. Stop blktrace 4. Run btrecord to convert traces into IO records 5. Run btreplay to replay IOs The IO stream characteristics during replay will try to respect the following characteristics of the original IO stream: 1. The IOs will target the same device(s) as originally seen. [One can alter this behavior by specifyin the -M option to btreplay, which allows one to remap IOs slated to one set of devices to a specified other set of devices.] 2. IO direction: the IOs will follow the same read/write (from-device/to-device) characteristics of the originating flow. [Note: By default replay will /not/ do writes, one must specify the -W option to do this. THis is a meager attempt to stop someone from shooting themselves in the foot (with a very large-caliber weapon).] 3. IO offset & size are maintained. 4. CPU: IOs are submitted on the originating CPU whenever possible. [Note: Since we are using asynchronous IO, IOs may be routed to another CPU prior to being processed by the block IO layer.] In order to try and replicate inter-IO timing as much as possible, btrecord will combine IOs "close in time" into one set, or bunch, of IOs. Then btreplay will replay all the IOs in one go (via asynchronous direct IO - io_submit). The size of the bunches are configurable via the -m flag to btrecord (which specifies the a time-based bunch size) and/or the -M flag (which specifies the maximum amount of IOs to put into a bunch). At the low-end, specifying '-M 1' instructs btrecord to act like fio - replay each IO as an individual unit. Besides the potential to remap devices (utilizing the -M option to replay, as noted above), one can also limit the number of CPUs on the replay machine - so if you have fewer CPUs on the replay machine you specify the -c option to btreplay. Lastly, one can specify the -N option to btreplay to instruct it to ignore inter-IO (inter-bunch of IOs) timings. Thus, this instructs btreplay to replay the bunches as fast as possible, ignoring the original delays between original IOs. The utilities include a write-up in the docs directory. Signed-off-by: Alan D. Brunelle <> Signed-off-by: Jens Axboe <>
Diffstat (limited to 'btreplay/Makefile')
1 files changed, 45 insertions, 0 deletions
diff --git a/btreplay/Makefile b/btreplay/Makefile
new file mode 100644
index 0000000..a8d2e3b
--- /dev/null
+++ b/btreplay/Makefile
@@ -0,0 +1,45 @@
+# COUNT_IOS - Counts struct io's left at end
+# DEBUG - Various and sundy debug asserts
+# NDEBUG - Defined: no asserts, Undefined: asserts
+CC = gcc
+CFLAGS = -Wall -W -O2 -g
+INCS = -I. -I.. -I../btt
+override CFLAGS += $(INCS) $(XCFLAGS) $(OCFLAGS)
+PROGS = btrecord btreplay
+LIBS = -laio -lrt
+all: depend $(PROGS)
+$(PROGS): | depend
+ $(MAKE) -C doc all
+ $(MAKE) -C doc clean
+clean: docsclean
+ -rm -f *.o $(PROGS) .depend
+%.o: %.c
+ $(CC) $(CFLAGS) -c -o $*.o $<
+btrecord: btrecord.o
+ $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+btreplay: btreplay.o
+ $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+ @$(CC) -MM $(CFLAGS) *.c 1> .depend
+ifneq ($(wildcard .depend),)
+include .depend