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 <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

1 files changed, 95 insertions, 0 deletions

diff --git a/btreplay/btrecord.h b/btreplay/btrecord.h
new file mode 100644
index 0000000..8026206
--- /dev/null
+++ b/btreplay/btrecord.h
@@ -0,0 +1,95 @@
+/*
+ * Blktrace record utility - Convert binary trace data into bunches of IOs
+ *
+ * Copyright (C) 2007 Alan D. Brunelle <Alan.Brunelle@hp.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#if !defined(__BTRECORD_H__)
+#define __BTRECORD_H__
+
+#include <asm/types.h>
+
+#define BT_MAX_PKTS	512
+
+/*
+ * Header for each bunch
+ *
+ * @nkts: 	Number of IO packets to process
+ * @time_stamp:	Time stamp for this bunch of IOs
+ */
+struct io_bunch_hdr {
+	__u64 npkts;
+	__u64 time_stamp;
+};
+
+/*
+ * IO specifer
+ *
+ * @sector:	Sector number of IO
+ * @nbytes:	Number of bytes to process
+ * @rw:		IO direction: 0 = write, 1 = read
+ */
+struct io_pkt {
+	__u64 sector;
+	__u64 nbytes;
+	__u32 rw;
+};
+
+/*
+ * Shorthand notion of a bunch of IOs
+ *
+ * @hdr: 	Header describing stall and how many IO packets follow
+ * @pkts: 	Individual IOs are described here
+ */
+struct io_bunch {
+	struct io_bunch_hdr hdr;
+	struct io_pkt pkts[BT_MAX_PKTS];
+};
+
+/*
+ * Header for each recorded file
+ *
+ * @version:	Version information
+ * @genesis:	Time stamp for earliest bunch
+ * @nbunches:	Number of bunches put into the file
+ * @total_pkts:	Number of packets to be processed
+ */
+struct io_file_hdr {
+	__u64 version;
+	__u64 genesis;
+	__u64 nbunches;
+	__u64 total_pkts;
+};
+
+static inline __u64 mk_btversion(int mjr, int mnr, int sub)
+{
+	return ((mjr & 0xff) << 16) | ((mnr & 0xff) << 8) | (sub & 0xff);
+}
+
+static inline void get_btversion(__u64 version, int *mjr, int *mnr, int *sub)
+{
+	*mjr = (int)((version >> 16) & 0xff);
+	*mnr = (int)((version >>  8) & 0xff);
+	*sub = (int)((version >>  0) & 0xff);
+}
+
+static char my_btversion[] = "0.9.3";
+static int btver_mjr = 0;
+static int btver_mnr = 9;
+static int btver_sub = 3;
+
+#endif