Messages in this thread | | | Date | Fri, 2 Apr 2004 01:02:22 +0100 | From | Jamie Lokier <> | Subject | Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build |
| |
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 - 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/
| |