On Tue, Aug 17, 2010 at 10:53 PM, Neil Brown <neilb@suse.de> wrote:
quoted text
>
> 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.

I think nfsd can simply update current_nfsd_time whenever the mtime it
reads from an inode is >= current_nfsd_time.  (The invariant you need
to maintain is that whenever nfsd reads an mtime, any timestamps
produced after that have a later time.  So just code it that way
directly.)

quoted text
>   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.

I believe this works.

quoted text
> [[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
> ]]

But I do not believe this works.

1) Modify file A
2) Modify file B
3) File A experiences one of those "occasional forward jumps in mtime"
(inode evicted + read back within 1 second)
4) mtimes on A and B are now out of order -- very bad

As Bruce mentioned, ext3 is a lost cause.

Regardless of any of this, however, the first step is to provide a
mount option to select the timestamp algorithm...  Because it is still
absurd that I cannot have accurate timestamps on my files here in the
21st century.

Once that is done, the rest is just providing the alternative
implementations and choosing defaults.

 - Pat
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/