Project

General

Profile

Bug #44409

log: the time precision of log is only milliseconds because the option log_coarse_timestamps doesn’t work well

Added by Ivan Guan 28 days ago. Updated 26 days ago.

Status:
Fix Under Review
Priority:
Normal
Assignee:
-
Category:
-
Target version:
% Done:

0%

Source:
Tags:
Backport:
octopus, nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature:

Description

version: nautilus 14.2.5

description:
client.log
...
2020-03-04 07:53:11.597 7f4809ffb700 15 client.83972 renew_caps requesting from mds.1
2020-03-04 07:53:11.597 7f4809ffb700 10 client.83972 renew_caps mds.1
2020-03-04 07:53:11.597 7f4809ffb700 20 client.83972 trim_cache size 0 max 16384
2020-03-04 07:53:11.598 7f4808ff9700 10 client.83972 handle_client_session client_session(renewcaps seq 2) v1 from mds.1
2020-03-04 07:53:12.598 7f4809ffb700 20 client.83972 trim_cache size 0 max 16384
2020-03-04 07:53:13.599 7f4809ffb700 20 client.83972 trim_cache size 0 max 16384
2020-03-04 07:53:14.599 7f4809ffb700 20 client.83972 trim_cache size 0 max 16384
2020-03-04 07:53:15.600 7f4809ffb700 20 client.83972 trim_cache size 0 max 16384
...

As we can see the time precision of log is only milliseconds in my test env though i set log_coarse_timestamps option to true and
restart the daemon. After reading the code about Log module i think the commit a747aeac13daf3dba43343120659e802cb569f6b may have
caused this bug because it leads to the Log:clock useless. Although we changed the Log::clock to get time by fine_now() by
setting log_coarse_timestamps option to true, the time format is still coarse because the Entry only get time through its own
clock member instead of Log::clock.

History

#2 Updated by Nathan Cutler 26 days ago

  • Status changed from New to Fix Under Review
  • Backport set to nautilus

#3 Updated by Nathan Cutler 26 days ago

  • Backport changed from nautilus to octopus, nautilus

Also available in: Atom PDF