Bug #6558


kstat: desire type for timestamps

Added by Garrett D'Amore almost 6 years ago. Updated over 5 years ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


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.


If folks agree, I'll prepare a changeset for this.

Actions #1

Updated by Josef Sipek almost 6 years ago

Would this be a timestamp with a fixed origin (similar to unix time) or something with an arbitrary point (similar to hrtime)?

Actions #2

Updated by Garrett D'Amore almost 6 years ago

It could be from a specific reference time (such as time since boot), which would work well for hrtime.

Ultimately for display to the user (in user space) we'd need a value that we can convert to an absolute time.

Actions #3

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.

Actions #4

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
Actions #5

Updated by Garrett D'Amore over 5 years ago

  • Category set to cmd - userland programs
  • Assignee set to Garrett D'Amore
  • % Done changed from 0 to 90
  • Tags deleted (needs-triage)
Actions #6

Updated by Richard Elling over 5 years ago

In this example, the %T (HH:MM:SS) is duplicated. I presume this is a copy-n-paste mistake since the code in the webrev shouldn't produce this?


Also available in: Atom PDF