Sorry...family is distracting me and I hit send before I was done writing this... On Sun, Sep 1, 2013 at 7:26 PM, Grant Grundler <grundler@xxxxxxxxxxxx> wrote: > 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 ...it works doesn't surprise me. My point is the user has to know how to map "some-kind-of-write" to "similar-kind-of-read" *and* result in the exact same generation numbers for the "verify reads". This feels "fragile" to me since it's implied behavior and not explicit behavior. >>> 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. "record which workload was used to write and use this record to automate the write/verify/verify_later steps" > 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 ...the given sequence of writes (vs a given sequence of reads) and (b) eliminates the burden of mapping write sequences to read sequences for the user who wants to verify a previously run workload. This very similar to the workflow you suggested (using --section) but more obvious. >> 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 Ok...I think I caught all my omissions...sorry about that. /o\ 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
