Here is my suggestion, taking into account the "U" to mean NaN and also I note that you can get deep negative spikes when the counters clock over (unless I'm mistaken they are 32 bit counters, even on a 64 bit kernel, and yes I do seem to have managed to clock at least one over).
LINE 202: print("${dev}_rtime.value ", ($rio_diff > 0 and $rtime_diff > 0) ? ($rtime_diff / $rio_diff) : 'U', "\n",
LINE 203: "${dev}_wtime.value ", ($wio_diff > 0 and $wtime_diff > 0) ? ($wtime_diff / $wio_diff) : 'U', "\n",
LINE 204: );
I've tested this for about half a day and it looks much nicer than the old version, less clutter. When IO is not happening on a drive, the trace goes away, and I think that's what should happen (people might for example use a drive only for backups or some other intermittent activity).
Here is my suggestion, taking into account the "U" to mean NaN and also I note that you can get deep negative spikes when the counters clock over (unless I'm mistaken they are 32 bit counters, even on a 64 bit kernel, and yes I do seem to have managed to clock at least one over).
LINE 202: print(" ${dev}_ rtime.value ", ($rio_diff > 0 and $rtime_diff > 0) ? ($rtime_diff / $rio_diff) : 'U', "\n",
LINE 203: "${dev}_wtime.value ", ($wio_diff > 0 and $wtime_diff > 0) ? ($wtime_diff / $wio_diff) : 'U', "\n",
LINE 204: );
I've tested this for about half a day and it looks much nicer than the old version, less clutter. When IO is not happening on a drive, the trace goes away, and I think that's what should happen (people might for example use a drive only for backups or some other intermittent activity).