lkml.org 
[lkml]   [2010]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Proposal: Use hi-res clock for file timestamps
On Tue, 17 Aug 2010 15:29:38 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Tue, Aug 17, 2010 at 08:39:41PM +0100, Alan Cox wrote:
> > > The problem with "increment mtime by a nanosecond when necessary" is
> > > that timestamps can wind up out of order. As in:
> >
> > Surely that depends on your implementation ?
> >
> > > 1) Do a bunch of operations on file A
> > > 2) Do one operation on file B
> > >
> > > Imagine each operation on A incrementing its timestamp by a nanosecond
> > > "just because". If all of these operations happen in less than 4 ms,
> > > you can wind up with the timestamp on B being EARLIER than the
> > > timestamp on A. That is a big no-no (think "make" or anything else
> > > relying on timestamps for relative times).
> >
> >
> > [time resolution bits of data][value incremented value for that time]
> >
> >
> > if (time_now == time_last)
> > return { time_last , ++ct };
> > else {
> > ct = 0;
> > time_last = time_now;
> > return { time_last , 0 };
> > }
> >
> > providing it is done with the same 'ct' across the fs and you can't do
> > enough ops/second to wrap the nanosecs - which should be fine for now,
> > your ordering is still safe is it not ?
>
> Right, so if I understand correctly, you're proposing a time source
> that's global to the filesystem and that guarantees it will always
> return a unique value by incrementing the nanoseconds field if jiffies
> haven't changed since the last time it was called.
>
> (Does it really need to be global across all filesystems? Or is it
> unreasonable to expect your unbelievably-fast make's to behave well when
> sources and targets live on different filesystems?)
>

I'm not sure you even want to pay for a per-filesystem atomic access when
updating mtime. mnt_want_write - called at the same time - seems to go to
some lengths to avoid an atomic operation.

I think that nfsd should be the only place that has to pay the atomic
penalty, as it is where the need is.

I imagine something like this:
- Create a global struct timespec which is protected by a seqlock
Call it current_nfsd_time or similar.
- file_update_time reads this and uses it if it is newer than
current_fs_time.
- nfsd updates it whenever it reads an mtime out of an inode that matches
current_fs_time to the granularity of 1/HZ.
If the current value is before current_kernel_time, it
is set to current_kernel_time, otherwise tv_nsec is incremented -
unless that increases
beyond jiffies_to_usec(1)*1000 beyond current_kernel_time.
- the global 'struct timespec' is zeroed whenever system time is set
backwards.

Then - providing the fs stores nanosecond timestamps - we should have stable,
globally ordered, precise (if not entirely accurate) time stamps, and a
penalty would only be paid when nfsd actually needs the information.


[[You could probably make ext3 work reasonably well by adding a mount option
which:
- advertises s_time_gran as 1
- when storing: rounds timestamps up to the next second if tv_nsec != 0
- when loading, setting the timestamp to the current time if the stored
number matches current_kernel_time().tv_sec+1
You would get occasional forward jumps in mtime, but usually when you
aren't looking, and at least you would not get real changes that are not
reflected in mtime
]]

NeilBrown


\
 
 \ /
  Last update: 2010-08-18 07:57    [W:0.136 / U:1.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site