On Wed, Feb 05 2014, Grant Grundler wrote: > Today, fio has two distinct phases of operation: workload and then verify. > > But there is this hack which is in-between those two: verify_backlog > which makes things a lot more complicated. This hack was added to > limit the amount of memory needed to track the IOs that needed to be > verify. I'm going to argue "verify_each_loop" could do the same thing > and keep fio internals simpler (strictly two phases). If the goal is > to have longer running, well defined workloads that can be verified, > then verifying after each iteration makes more sense. In other words, > the jobs should define a workload limit (amount of IO or time) and > then iterate that constraint as many times as they want to reach the > duration they want. > > Thoughts?
We've actually caught actual bugs with the verify_backlog in the past, where you want verify closer to when the write has happened. So I'd prefer if we fix those up instead. For memory reduction, I think the experimental_verify is the way to go. Basically have roll back support for any of the generated offsets etc, so we don't need to track it at all. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
