Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build

[Jamie Lokier <jamie at shareable dot org>]

Andi Kleen wrote:
> > However, I'd say that this should probably be fixed in the kernel,
> > e.g. by not reporting high-precision time stamps in the first
> > place if the file system cannot store them ...
> 
> Interesting. We discussed the case as a theoretical possibility when
> the patch was merged, but it seemed to unlikely to make it worth
> complicating the first version.
> 
> The solution from back then I actually liked best was to just round
> up to the next second instead of rounding down when going from 1s 
> resolution to ns.

Files spontaneously getting newer is also problem, although the
consequence is usually less severe than spontaneously getting older.

> -	raw_inode->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
> -	raw_inode->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec);
> -	raw_inode->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
> +	/* round up because we cannot store nanoseconds. This avoids
> +	   the time jumping back when the inode is loaded again. */
> +	raw_inode->i_atime = cpu_to_le32(inode->i_atime.tv_sec + 1);
> +	raw_inode->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec + 1);
> +	raw_inode->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec + 1);

The patch always increments the stored seconds by one.  If an inode
is read, dirtied, then stored, the seconds fields will all be
incremented by 1 every time that happens, won't they?  I.e. every
change to atime interleaved by a flush will increment the seconds
field of ctime and mtime, won't it?

To round up the time properly, I think you need to change the code
that reads the inode, so that newly read inodes get a tv_nsec value of
999999999, and leave the writing code alone.

-- Jamie