Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build

[Andrew Morton]

Andi Kleen <ak@xxxxxxx> wrote:
>
> he 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);

I think this will cause the inode timestamps to keep on creeping forwards.

How about in ext3_read_inode() you do:

	inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime);
	inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime);
	inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime);
-	inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0;
+	inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 999999999;

?

It still has problems, but I think they're smaller ones.
-
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/