On 03/18/2016 09:36 AM, Nathan Scott wrote:
----- Original Message -----
This time on FreeBSD (with the struct timeval tv_sec fix in place, although
that won't have changed anything because the type remains c_long here) ...
Timestamps and no headers
Fri Aug 1 14:34:51 2014 sda 0.0 0.0 0.0 0.0 0.0
0.0 0.00 0.00 0.0 0.0 0.0 0.0
Fri Aug 1 14:34:51 2014 sdb 0.0 0.0 5.0 6.0 24.0
8.0 2.91 0.00 0.4 0.4 0.3 0.4
Fri Aug 1 04:34:52 2014 sda 0.0 0.0 24.0 0.0 816.0
0.0 34.00 0.23 9.6 9.6 0.0 19.0
Fri Aug 1 04:34:52 2014 sdb 5.0 0.0 1308.0 5.0 53363.0
7.0 40.65 1.15 0.9 0.9 0.2 61.1
Fri Aug 1 04:34:53 2014 sda 0.0 0.0 7.0 0.0 517.0
0.0 73.86 0.09 12.1 12.1 0.0 6.2
This is all correct EXCEPT the time spontaneously changes from 14 hr to 04 hr
after the 2nd sample ... and stays at 04 hr for the rest of the archive.
14 is correct, 10 is wrong.
actually, 14 is correct and 04 is wrong, which also happens to be the
timezone difference in the archive verses UTC (-10).
# pmdumplog -L archives/dm-io
Log Label (Log Format Version 2)
Performance metrics from host slick
commencing Fri Aug 1 14:34:50.247 2014
ending Fri Aug 1 14:37:49.246 2014
Archive timezone: EST-10
PID for pmlogger: 31332
So maybe somehow pmCtime spontaneously 'forgot' it's timezone and
reverted to UTC? Environment corrupted?? Does freebsd have valgrind?
I have no clue on this one!
Bizarre - I wonder if this is reproducible with pmval or something simpler?
AFAICT, src/pcp/iostat/pcp-iostat.py is using pmCtime and has done all the
same timezone-setting steps (via pmGetOptions) that the C tools would do.
|