Messages in this thread Patch in this message | | | Date | Thu, 1 Apr 2004 22:09:57 +0200 | From | Andi Kleen <> | Subject | Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build |
| |
On Thu, 1 Apr 2004 21:28:20 +0200 (CEST) Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> 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.
-Andi
e.g. like this for ext3 (untested). Does that fix your problem?
diff -u linux-2.6.5rc3-work/fs/ext3/inode.c-o linux-2.6.5rc3-work/fs/ext3/inode.c --- linux-2.6.5rc3-work/fs/ext3/inode.c-o 2004-04-01 22:07:43.000000000 +0200 +++ linux-2.6.5rc3-work/fs/ext3/inode.c 2004-04-01 22:08:49.000000000 +0200 @@ -2624,9 +2624,11 @@ } raw_inode->i_links_count = cpu_to_le16(inode->i_nlink); raw_inode->i_size = cpu_to_le32(ei->i_disksize); - 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); raw_inode->i_blocks = cpu_to_le32(inode->i_blocks); raw_inode->i_dtime = cpu_to_le32(ei->i_dtime); raw_inode->i_flags = cpu_to_le32(ei->i_flags);
- 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/
| |