-
James Simmons authored
Replace cfs_time_current_sec() to avoid the overflow issues in 2038 with ktime_get_real_seconds(). Besides changing struct scrub_file sf_time_* fields to time64_t for usage with ktime_get_real_seconds() the other fields can also be moved to time64_t as well since we don't need precision better than one second for the scrubbing code. The dr_* time fields in struct osd_iobuf are jiffies which does get reporting with the histograms. This was with the thinking that jiffies equal milliseconds which is not always the case. Since we need better than one second resolution move dr_* time fields to ktime. This way the value passed to lprocfs_oh_tally_log() will always be in milliseconds. Change-Id: Ibce7f7d9f972c8d3188271950f68dcda7663676f Signed-off-by:
James Simmons <uja.ornl@yahoo.com> Reviewed-on: https://review.whamcloud.com/29857 Tested-by: Jenkins Tested-by:
Maloo <hpdd-maloo@intel.com> Reviewed-by:
Fan Yong <fan.yong@intel.com> Reviewed-by:
Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com>
James Simmons authoredReplace cfs_time_current_sec() to avoid the overflow issues in 2038 with ktime_get_real_seconds(). Besides changing struct scrub_file sf_time_* fields to time64_t for usage with ktime_get_real_seconds() the other fields can also be moved to time64_t as well since we don't need precision better than one second for the scrubbing code. The dr_* time fields in struct osd_iobuf are jiffies which does get reporting with the histograms. This was with the thinking that jiffies equal milliseconds which is not always the case. Since we need better than one second resolution move dr_* time fields to ktime. This way the value passed to lprocfs_oh_tally_log() will always be in milliseconds. Change-Id: Ibce7f7d9f972c8d3188271950f68dcda7663676f Signed-off-by:
James Simmons <uja.ornl@yahoo.com> Reviewed-on: https://review.whamcloud.com/29857 Tested-by: Jenkins Tested-by:
Maloo <hpdd-maloo@intel.com> Reviewed-by:
Fan Yong <fan.yong@intel.com> Reviewed-by:
Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com>