| 844ea60273f4e7862150d9c6430cdb15768e2f34 |
|
20-Feb-2014 |
Jens Axboe <axboe@fb.com> |
Add support for the Google xxhash checksumming function
It's a lot faster than the other software defined ones, so will
be a useful alternative for the cases where crc32c-intel isn't
available.
Signed-off-by: Jens Axboe <axboe@fb.com>
/external/fio/verify.h
|
| ce35b1ece06ce27ebff111e47c2a6610c311a92b |
|
14-Jan-2014 |
Jens Axboe <axboe@kernel.dk> |
Add option for specifically setting buffer contents
Fio can use zeroes, slightly scrambled data, full random data,
or specifically compressible data. With this option, the user
can now fully control the pattern written, similarly to how
verify_pattern works for verify=meta.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
/external/fio/verify.h
|
| dc5bfbb227f1af83adf0b686d147b7ae2107c144 |
|
10-Apr-2013 |
Jens Axboe <axboe@kernel.dk> |
Merge in crc32c-intel probe
Then we can kill the option callback.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
/external/fio/verify.h
|
| d3a173a927084660c365d6aa162016ebb0746946 |
|
23-Feb-2012 |
Jens Axboe <axboe@kernel.dk> |
Remove holes in verify_header structure
Shrink the magic and verify_type members, and reorder so that
it packs nicely. Incompatible change, write workloads must be
re-run.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
/external/fio/verify.h
|
| f65d1c2663ac6007eac1a2063fe25b4275d013e4 |
|
22-Feb-2012 |
Jens Axboe <axboe@kernel.dk> |
Add checksum to verify_header
Currently we don't know if the verify_header itself is
valid when pulled off a disk. While it will fail verify
if it is, fio might then confuse the 'expected' and
'received' data since it re-generates the corrupted
crc with the seed stored. But if the seed is corrupt,
then we fail.
So checksum the verify header, so that we know for a fact
whether the header is valid or not.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
/external/fio/verify.h
|
| 92bf48d530ab09bae4058df711c4723c73da51b9 |
|
14-Jan-2011 |
Jens Axboe <jaxboe@fusionio.com> |
Streamline pattern/meta verifies instead of special casing them
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/verify.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/verify.h
|
| 03e20d687566753b90383571e5e152c5142bdffd |
|
02-Jan-2011 |
Bruce Cran <bruce@cran.org.uk> |
First snapshot of FIO for Windows
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/verify.h
|
| cbe8d7561cf6d81d741d87eb7940db2a111d2144 |
|
14-Jul-2010 |
Radha Ramachandran <radha@google.com> |
Reuse filled pattern
I made changes to fio so we wld re-use the already populated io_u
buffer (when there is a non-random pattern) during writes. That way
only the header will be re-calculated for every I/O. This way the
buffer wld get populated in the beginning and as long as the
subsequent ios using the same io_u structure are writes and have same
or less block size, it wld get re-used. If any of the subsequent i/o
is a read or has a block size greater than the pre-filled one, then
the buffer is invalidated and will be re-filled at the next write.
Reason for this risky change: (Performance)
I tested this change on a tmpfs(with no swap backing), with the
following config file:
[sscan_write]
filename=/mytmpfs/datafile.tmp
rw=write
bs=64k
size=3G
ioengine=libaio
iodepth=1024
iodepth_low=512
runtime=10800
bwavgtime=5000
thread=1
do_verify=0
verify=meta
verify_pattern=0x55aaa55a
verify_interval=4k
continue_on_error=1
fio-1-41-6 gave 306MB/s and the new change had a performance of 1546MB/s
Side effects/Risks:
There is a risk with this fix, that if the buffer gets corrupted then
the subsequent writes will also be corrupt. I think for both
sequential writes and random writes (with verify, where the I/O log is
replayed) we shld be able to find the first I/O that started with the
corruption and if the buffer is getting corrupted, there are other
issues here.
Testing:
I have tested this fix with sequential write(verify)/random read write
mix combination(with verify).
I think I have taken care of most of the case, but please let me know
if there is anything I have missed. I have attached the patch along
with this email. I think the performance improvement outweighs the
risk associated with the fix. But I will let you decide if you wld
like to pick it up.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/verify.h
|
| 34644af59bd9232cc2948baf4f94b6534cb0a120 |
|
17-Jun-2010 |
Jens Axboe <jaxboe@fusionio.com> |
md5: fix bug in hash size
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
/external/fio/verify.h
|
| bc77f56f79f6ae155e9eb26263ed686ef28b47ec |
|
23-Feb-2010 |
Jens Axboe <jens.axboe@oracle.com> |
Fix bug in sha256 verify
It was using twice as large data block as it should have been,
causing verify failures.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
/external/fio/verify.h
|
| 7c353ceb3257b132f4c98326046b42201e070731 |
|
09-Aug-2009 |
Jens Axboe <jens.axboe@oracle.com> |
Add Linus' optimized sha1 hash for checksum
It does appear to be pretty fast.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
/external/fio/verify.h
|
| e8462bd8250cf3ff2d41f17e1a4d4cefc70b6b37 |
|
06-Jul-2009 |
Jens Axboe <jens.axboe@oracle.com> |
Add support for async IO verification offload
This adds support for setting up a number of IO verification offload
threads, instead of doing the offload inline. An option for controlling
the CPU affinity of those threads are always added.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
/external/fio/verify.h
|
| 4f5af7b2370a6d3e64bc5128905c1aa8b0dc51b0 |
|
03-Jun-2009 |
Jens Axboe <jens.axboe@oracle.com> |
Cleanup verify headers
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
/external/fio/verify.h
|