On Fri, Aug 30, 2013 at 9:19 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On Fri, Aug 30 2013, Grant Grundler wrote: ... >> 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. Ok - That > >> 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. Ok. > 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. two observations here; 1) this seems like a "good practice" (record was done and use the to automate the steps). It won't matter too much what the parameters are to make this work. 2) whoever puts together the job file, has to know which read workloads complement a given write workload. It would be "nicer" (from a user PoV) to just add another parameter to say "verify the writes in a given job section". This does two things: (a) explicitly documents the intent is to verify > 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. I'm certainly not dismissing current implementation as useless. In fact, it's sounding fio is already doing exactly what I want. I'm only arguing how to check data again later is not obvious (ie not accessible to most users). I've just read through the README and HOWTO. I will think more about how I can make this more accessible. Maybe just providing an example jobfile with comments would be enough. The HOWTO should probably refer to example/ more often. > 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? Sure. "data_rentention_check" would better as a chapter title for documentation. I'll see if the existing "--readonly" flag could behave like I expect. thanks! grant -- 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
