Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
From: Jamie Lokier
Date: Thu Apr 01 2004 - 19:05:17 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/