kstat: desire type for timestamps
occasionally a real time (64-bit hrtime?) is useful, and it would be nice to express this in kstats. We have snaptime and crtime already, so adding a discrete kstat type would be useful. (For example, I want to record the time when a configuration changed, or the time when a device was reset.) I could print this using strings, but using a 64-bit integer would be much more efficient, and avoid trying to do hard time calculations in the kernel.
I'm thinking KSTAT_TYPE_TIMESTAMP
If folks agree, I'll prepare a changeset for this.
Updated by Peter Tribble almost 6 years ago
Given that you can put arbitrary 64-bit data into a named kstat, why would this be necessary?
Presumably it wouldn't be a new kstat type - that seems highly undesirable (apart from the fact that named kstats ought to cover most usage). As a data type, possibly, but given that the underlying 64-bit data type is already present that seems unnecessary.
Updated by Garrett D'Amore over 5 years ago
Yes, this is a new data type, KSTAT_DATA_TIME
I'm using an hrtime_t, adding a new member, "t", to the kstat_named_t structure.
Additionally, there are changes to the kstat command to display these in a meaningful form (and also btw the snaptime, and times associated kstat_io_t and kstat_timer_t.) What I've done is add a flag to kstat -H, that formats these according to its argument:
-H d - format as UNIX date output (accuracy limited to 1 sec)
-H u - format as UNIX seconds since epoch (1 sec accuracy)
-H n - format as UNIX nanoseconds since epoch (only 1 usec accuracy tho)
-H I - format as ISO 8601 date in local time zone (including usec)
-H Z - format as ISO 8601 date in UTC (including usec)
With no -H (or any arg to -H other than above), the default behavior is retained.
For the non-numeric values above, the JSON output is properly quoted. (Btw, numeric values that are "large" may cause breakage / accuracy loss in JSON due to float64 representation limitations.)
Furthermore, the normalized times above have at best a 1 usec accuracy. (Although the -H n format will show nanosecs, and they are relatively correct to each other based on gethrtime, the absolute accuracy will be up to 1us off.) This is because the real-time clock exposed by gettimeofday() has a 1us accuracy. Furthermore, the normalization technique I use relies on a call to gethrtime(), which itself can take upwards of 200 ns to execute from userland.
Still, the end result here is that kstat's time displays become much much more meaningful to the average human, since they now can have normalized times, without having to convert from seconds since boot to something absolute.
Here's an example:
> ./kstat -H Z zfs::zfetchstats module: zfs instance: 0 name: zfetchstats class: misc crtime 2016-01-26T08:44:0608:44:06.895081Z hits 16647 max_streams 2473859 misses 2478938 snaptime 2016-01-26T13:12:5513:12:55.022271Z