By Henk Vandenbergh-Oracle on Mar 06, 2009
Vdbench Data Validation (-v) gives Vdbench the ability to make sure that data once written can be read back and compared to make sure that the data is still correct. To accomplish this, Vdbench has a large table in memory that tells him what was written where. Once Vdbench terminates that in-memory table of course is gone.
By using the '-j' execution parameter Vdbench does not only do Data Validation, it also maintains a Journal file that is used to keep a copy of the in-memory table, allowing upon a Vdbench Journal restart (-jr) for the table to be recovered so that Vdbench knows what was written in the previous run. (There is a 'Data Validation and Journaling' chapter in the doc explaining all this).
I saw an interesting case yesterday: one of my users was running Journaling without really needing it. This can cause problems. Why? Journaling for each write to a target lun causes two synchronized writes of a journal record, one before the write to the lun, and one just after the write to the lun is completed. Synchronized writes, especially when the write is done against a storage device that does not have non-volatile write cache, can be pretty slow. The result of that is that the IOPS running against the lun that is being tested is quite lower than when you do not use journaling.
The objective of the test in question was to recreate a data integrity problem in a lab environment. This data integrity problem in theory can and usually will be faster to recreate when running higher iops. If for instance your problem happens after 100,000 i/o operations, the higher your IOPS, the sooner you hit the problem.