On 03/13/2014 12:30 PM, Stijn De Weirdt wrote:
can we retest the clock skew condition? or get the value that the skew is?
'ceph health detail --format=json-pretty' (for instance, but 'json' or
'xml' is also allowed) will give you information on a per-monitor basis
of both skew and latency as perceived by the monitors.
-Joao
ceph status gives
health HEALTH_WARN clock skew detected on mon.ceph003
in a polysh session (ie parallel ssh sort of thing)
ready (3)> date +%s.%N
ceph002 : 1394713567.184218678
ceph003 : 1394713567.182722045
ceph001 : 1394713567.185351320
(they are ptp synced)
stijn
On 03/13/2014 01:19 PM, Gandalf Corvotempesta wrote:
2014-03-13 12:59 GMT+01:00 Joao Eduardo Luis <joao.luis@xxxxxxxxxxx>:
Anyway, most timeouts will hold for 5 seconds. Allowing clock drifts
up to
1 second may work, but we don't have hard data to support such
claim. Over
a second of drift may be problematic if the monitors are under some
workload
and message handling is delayed -- in which case other timeouts may
have to
be adjusted, not only to account for the clock skew but the amount of
work
the monitor has to deal with.
I think that 1 seconds is too much.
I would like to try with .100 or .200 not with seconds
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
Joao Eduardo Luis
Software Engineer | http://inktank.com | http://ceph.com
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
