Thanks Sitsofe, I'll try crc32c then. Hopefully Dell servers should support it :) On Sun, Apr 12, 2015 at 1:51 PM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > On 12 April 2015 at 11:12, Samuel Shapiro <samuel.sh79@xxxxxxxxx> wrote: >> Thanks for the great answer Sitsofe :) >> Will stick to md5 verification while testing FS data integrity. > > If fio is in any shape or form CPU bound during writing or > verification I'd probably hint to you that crc32c-intel might be > better tradeoff if fio is running on recent Intel hardware. If you > can't use that (because you aren't on that hardware) you could use > xxhash instead. Both crc32c-intel and xxhash will "detect" less > corruptions than md5 (their checksum is smaller) but they can be > dramatically faster and perhaps allow you to get more runs / more > concurrency in and will still detect common problems. > > I failed to answer question 3. of your original mail: > >> 3. How can I parse ".state" file so I could compare its data to >> original file on storage? > > You only need to use this file if the writing pass is interrupted > before it could be fully completed (so you know when to stop > verifying). I don't think it records the contents of the data being > written but rather how starting parameters and how far along a given > data generation sequence you got (so you have enough to replay it > later)... > > Generally speaking and assuming the verification header part of a > block isn't corrupt, verify_dump can be used to make fio dump the > expected and mismatched data into two files for later inspection when > a mismatch is found. If memory serves, non important parts of the > header section may not match between the expected and actual dumps > (e.g. padding between the real values might not match up). > > -- > Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
