On Mon, Feb 9, 2015 at 6:27 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 02/09/2015 08:25 AM, Andrey Kuzmin wrote: >> >> On Mon, Feb 9, 2015 at 6:17 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: >>> >>> On 02/09/2015 02:39 AM, Andrey Kuzmin wrote: >>>> >>>> >>>> On Mon, Feb 9, 2015 at 6:53 AM, Gwendal Grignou <gwendal@xxxxxxxxxxxx> >>>> wrote: >>>>> >>>>> >>>>> When commands when requeued for the verify operation, >>>>> their start time was not reset, resulting in bogus latency graphs. >>>> >>>> >>>> >>>> Does it really make sense to account for the verification pass in the >>>> latency profile? >>> >>> >>> >>> Why not? If you are doing a full write then verification, you get a full >>> set >>> of separate read and write latencies. >> >> >> I'd rather get them on a per-pass basis. Imagine an r/w workload being >> done with verification pass (just to be on the safe side): I'd rather >> keep read-only verification pass latencies separate from the primary >> workload latency profile. YMMW :). > > > Sure, if it's a mixed read/write workload and you verify after the fact, > then it could be handy to have the two "different" kinds of reads separate. May be a case for an extra option to control latency profile aggregation (disable_verify_lat ?)? > But that's really orthogonal to the issue being fixed by Gwendals patch... Sure, it has just brought up an earlier point :). Regards, Andrey > > > -- > 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
