Sukadev Bhattiprolu wrote:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
|
|
| > h->fl_type = lock->fl_type;
| > + h->fl_type_prev = lock->fl_type_prev;
| > h->fl_flags = lock->fl_flags;
| > + if (h->fl_type & F_INPROGRESS &&
| > + (lock->fl_break_time > jiffies))
| > + h->fl_rem_lease = (lock->fl_break_time - jiffies) / HZ;
|
| Hmmm -- we have a ctx->ktime_begin marking the start of the checkpoint.
| It is used for relative-time calculations, for example, the expiry of
| restart-blocks and timeouts. I suggest that we use it here too to be
| consistent.
Well, I started off using ktime_begin but discussed this with John Stultz
(CC'd here) who pointed out that mixing different domains of time is likely
to cause errors. ktime is an absolute time and fl_break_time uses jiffies -
a relative time.
I think use of ktime_begin for restart_blocks is fine (since they use
ktime_t) but using ktime_t for file leases and converting between jiffies
and nanoseconds could be a problem, unless we convert fl_break_time to
seconds.
IOW, can we leave the above computation of ->fl_rem_lease for now ?
The data on restart_blocks keep relative time - it's the the time
to expiry relative to ktime_begin (which is absolute).
ktime_begin merely gives a reference point in time against which
all other time-related values should be saved. The advantage is
that all time computation are relative to the same point in time
at checkpoint/restart - the time when the ktime_begin is set. It's
more consistent this way.
I don't see the problem with jiffies vs ktime - there are functions
to convert between different units (see jiffies.h). Even if you are
concerned about reducing the resolution because of a conversion -
well, it isn't realistic to expect nano-sec resolution after restart...
Oren.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
