Re: [RFC][PATCH 2/3][cr][v2]: Checkpoint/restart file leases

[Oren Laadan <orenl@cs.columbia.edu>]

Sukadev Bhattiprolu wrote:
> Oren Laadan [orenl@cs.columbia.edu] 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.