On Fri, Aug 30 2013, Grant Grundler wrote: > On Fri, Aug 30, 2013 at 3:03 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: > ... > > It's a feature. It allows you to run a write only workload, then run a later > > identical workload as read only but verifying the previously written data. > > By unconditionally adding a "stale data" check, aren't we breaking > that "feature"? > > Running a read-only workload won't know which type of workload was > previously run (random vs mixed vs sequential writes). This puts the > burden on the user to "reverse engineer" which read workload > corresponds to the previous write workload. That's obviously true, you can't just verify a "disk" and expect that to work. But you CAN change rw=some-kind-of-write to rw=similar-kind-of-read and expect it to verify correctly. And it does. > I'd prefer we break this feature and replace it with a "data rention > check" parameter. It would be alot easier if one can run the exact > same command line later but just add --data_retention_check to > indicate it doesn't need to actually re-run the workload (reads or > writes). > > How do you want to proceed? I'm fine with adding some option to control this, but I would not like to breka the existing behaviour. People actually rely on that. Consider a job file with all the settings in the global part. The write and read parts are separate, you invoke fio with the --section= you want to run. That's the use case of the read verifies, not guessing on what you originally ran and attempt to verify that. That would be a very haphazard approach to data verification, that's not a valid use case. But don't dismiss the read verification as useless, it definitely isn't. That being said, data_retention_check isn't a very explanatory name. If I saw that option, I'd think I'd add it to my write verify to get stronger checking. But if it's flipping the workload, then it needs to have a more descriptive name. Can we please find something that better describes how it changes fio behaviour? -- Jens Axboe -- 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
