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. But that's really orthogonal to the issue being fixed by
Gwendals patch...
--
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
