e1457298d009911f05a1860f3bd15ea54f019984 |
|
04-Dec-2014 |
Jens Axboe <axboe@fb.com> |
Use specified compression/pattern for verify buffers too Signed-off-by: Jens Axboe <axboe@fb.com>
/external/fio/lib/rand.h
|
fd1583f077bb4f77a462ca1ac7274f443f9372ce |
|
04-Dec-2014 |
Jens Axboe <axboe@fb.com> |
Use specified buffer_pattern (if given) for all io_u fills For compression, we use a fixed '0' pattern. But if the user specified a pattern to use in the job file, then we should use that instead. It could slightly skew the compression ratio for long patterns, but that is to be expected. Signed-off-by: Jens Axboe <axboe@fb.com>
/external/fio/lib/rand.h
|
e66dac263f65ed4d762299dcdc4f9a6a3fb427a7 |
|
22-Sep-2014 |
Jens Axboe <axboe@fb.com> |
Basic support for dedupe This adds and option, dedupe_percentage, that controls how many of the write IO buffers are identical. For instance, if this is set: dedupe_percentage=70 then 70% of the write IO buffers will have identical contents. The specific contents are, as before, controlled by the various options that set buffer contents or buffer compressibility. Signed-off-by: Jens Axboe <axboe@fb.com>
/external/fio/lib/rand.h
|
9c42684e32325da26e862280388798343c5f1305 |
|
02-Mar-2012 |
Jens Axboe <axboe@kernel.dk> |
Add buffer_compress_percentage The option is pending testing, so not documented yet. Signed-off-by: Jens Axboe <axboe@kernel.dk>
/external/fio/lib/rand.h
|
3545a109a2cfe5ab22969ef453dc049db47f0b68 |
|
31-Aug-2011 |
Jens Axboe <jaxboe@fusionio.com> |
Ensure that buffer contents are random across jobs as well Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/lib/rand.h
|
2615cc4b28e7d0e436a625dff92e6a71ccc6c49b |
|
28-Mar-2011 |
Jens Axboe <jaxboe@fusionio.com> |
Switch to using our internal Tausworthe based random generator for offsets It's both faster and more exhaustive than what is available on glibc on my test systems. So no downsides, and the upside of having the same offset generator across all platforms. This will change the random series, so could alter performance for your workload since the pattern will be different in sequence. There's an option to revert to the OS generator, you can add use_us_rand=1 on your job files to retain the old generator offsets. Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/lib/rand.h
|
7d9fb455aadc0c0363489591775496f27f4a560a |
|
11-Jan-2011 |
Jens Axboe <jaxboe@fusionio.com> |
When verify fails, dump the good/bad blocks to files This makes it easy to compare afterwards to see what kind of corruption was experienced. Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/lib/rand.h
|
637ef8d9f7645135cf4829894d1e3983cd7a042e |
|
21-Jun-2010 |
Jens Axboe <jaxboe@fusionio.com> |
Speedup verify random fills by 10-15x Move the pseudo-random helper into lib/rand.c and use that from the verify populate as well. Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/lib/rand.h
|
1fbbf72e16c27a6fda636db3891a41cd37dc6666 |
|
25-Mar-2010 |
Jens Axboe <jens.axboe@oracle.com> |
First step at speeding up io_u rand refill Makes it 3x faster here. Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
/external/fio/lib/rand.h
|