path: root/btreplay
AgeCommit message (Collapse)Author
2013-08-01btreplay: use sysconf to get the number of configured cpusNathan Zimmer
We should use the standard methods for getting the number of cpus in the system when they are available. It is good practice to leave the old ways in place for people stuck on older systems. Cc: Jens Axboe <> Signed-off-by: Nathan Zimmer <> Signed-off-by: Jens Axboe <>
2013-08-01btreplay: Machines are now large enough that holes need to be dealt withNathan Zimmer
The current method fails if once we hit the first offlined cpu. This will correct that case. However this still underreports the number cpus if the last cpu are offlined. Cc: Jens Axboe <> Signed-off-by: Nathan Zimmer <> Signed-off-by: Jens Axboe <>
2012-02-01Remove extraneous malloc in find_input routinesEric Sandeen
No point in malloc()ing space if we just immediately overwrite the pointer via strdup. That'll leak some space. Signed-off-by: Eric Sandeen <> Signed-off-by: Jens Axboe <>
2010-11-29Fixed build warning for btreplayAlan D. Brunelle
btreplay.c:1332: warning: comparison between signed and unsigned integer expressions
2010-04-20blktrace: add back conversionEdward Shishkin
Fixup for bz 502889. Problem: when executing with /dev/cciss/foo (long path names) btreplay complains (No such file or directory). Bug: Missed back conversion of erscores to slashes. Solution: Convert underscores to slashes to restore device names that have larger paths. Signed-off-by: Edward Shishkin <> Signed-off-by: Jens Axboe <>
2010-02-22add libpthread to btreplay/Makefile LIBSEric Sandeen
Fedora linking changes picked this up: /usr/bin/ld: btreplay.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/ so try adding it to the linker command line See also Signed-off-by: Eric Sandeen <> Signed-off-by: Jens Axboe <>
2009-05-11fix max-pkts option inconsistenciesEric Sandeen
This is for RH bug 498426, btrecord doesn't recognize --max-pkts and --max-packets cmd line options Usage text and some documentation references "--max-pkts" and the man page references "--max-packets" but the getopts code is looking for --max_pkts. I'm not sure if it's best to make the code match the majority of the docs, or fix the docs to match the code? This patch does the former, but I'm not picky if you want to go the other way :) Signed-off-by: Eric Sandeen <> Signed-off-by: Jens Axboe <>
2009-02-17O_NOATIME isn't always presentJens Axboe
Signed-off-by: Jens Axboe <>
2008-10-29Moved btrecord/btreplay to version 1.0.0Alan D. Brunelle
2008-07-01spelling and grammar fixes for btreplay.texJeff Moyer
Signed-off-by: Jens Axboe <>
2008-05-05Add -x accellerator optionLuis Useche
This patch adds a new functionality to the btreplay tool, the -x option. This parameter accelerate the replication by the factor specified. This means that the stall time is divided by the number introduced. Signed-off-by: Jens Axboe <>
2008-02-22Don't like btrecord against libaio and librt, as it doesn't use any of their ↵Bas Zoetekouw
symbols Signed-off-by: Jens Axboe <>
2007-10-10Added O_NOATIME to replay fileAlan D. Brunelle
Signed-off-by: Alan D. Brunelle <>
2007-10-10Fix segfault in replay_sub when verbose is 1Joshua Root
tip->vfp is only initialised when verbose > 1, so we must only use it under the same circumstance. Signed-off-by: Alan D. Brunelle <>
2007-10-05Converted fatal from macro to inlineAlan D. Brunelle
Hopefully this will fix a gcc-4.2.1 warning. Signed-off-by: Alan D. Brunelle <adb@korik.(none)>
2007-10-02Add btrecord/btreplay capabilityAlan D. Brunelle
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 <>