On 2/12/07, Andi Kleen <[email protected]> wrote:
> The bigger problem is getting a file system that support it.
Andi,
It seems that the part that's not returning nanosecond is in the code
below. I've modified it, and now stat() is returning st_mtim.tv_nsec
correctly.
I've tested it on ext2 and reiserfs, and both seems to be working.
I don't know why "t.tv_nsec = 0;" was set in the code. Any idea?
Thanks,
Jeff.
--- linux/kernel/time.c.org 2007-02-13 08:43:08 +0800
+++ linux/kernel/time.c 2007-02-13 08:52:29 +0800
@@ -86,7 +86,6 @@
if (get_user(tv.tv_sec, tptr))
return -EFAULT;
- tv.tv_nsec = 0;
err = security_settime(&tv, NULL);
if (err)
@@ -269,7 +269,6 @@
if (gran <= jiffies_to_usecs(1) * 1000) {
/* nothing */
} else if (gran == 1000000000) {
- t.tv_nsec = 0;
} else {
t.tv_nsec -= t.tv_nsec % gran;
}
On Tue, 2007-02-13 at 16:38 +0800, Jeff Chua wrote:
> On 2/12/07, Andi Kleen <[email protected]> wrote:
>
> > The bigger problem is getting a file system that support it.
>
>
> Andi,
>
> It seems that the part that's not returning nanosecond is in the code
> below. I've modified it, and now stat() is returning st_mtim.tv_nsec
> correctly.
>
> I've tested it on ext2 and reiserfs, and both seems to be working.
>
>
> I don't know why "t.tv_nsec = 0;" was set in the code. Any idea?
it was there to avoid the following situation:
on disk it's still in seconds
kernel has the inode in memory, with a recently updated times
user asks for it, gets nanoseconds data
kernel evicts inode to disk
user asks again,
kernel reads from disk (in whole seconds only on disk)
kernel reports a DIFFERENT time than it did before
user program gets confused
this actually happens, make is one of those cases that get confused for
example..
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
> It seems that the part that's not returning nanosecond is in the code
> below. I've modified it, and now stat() is returning st_mtim.tv_nsec
> correctly.
>
> I've tested it on ext2 and reiserfs, and both seems to be working.
>
>
> I don't know why "t.tv_nsec = 0;" was set in the code. Any idea?
The first hunk doesn't make any sense. stime() will never know anything about
nanoseconds. You're just putting uninitialized memory in there.
The truncation you removed in the second was deliberately added for the old file
systems that don't support higher granuality *times. Otherwise
the time can jump backwards between a inode that is still cached
in memory and one that is saved/restored from disk. Several programs
(including make) assume this cannot happen, so the kernel prevents it
by always rounding.
If you want ns resolution you need a file system that supports it:
that's currently XFS, JFS, NTFS/CIFS (resolution is lower, but < 1s), NFSv[34], UDF,
with suitable servers, tmpfs/ramfs/hugetlbfs. ext4 ns support is being worked on,
BTW the real max resolution supported in the kernel right now is jiffies.
-Andi
On 2/13/07, Arjan van de Ven <[email protected]> wrote:
> it was there to avoid the following situation:
> on disk it's still in seconds
On 2/13/07, Andi Kleen <[email protected]> wrote:
> If you want ns resolution you need a file system that supports it:
> that's currently XFS, JFS, NTFS/CIFS (resolution is lower, but < 1s), NFSv[34], UDF,
> with suitable servers, tmpfs/ramfs/hugetlbfs. ext4 ns support is being worked on,
>
> BTW the real max resolution supported in the kernel right now is jiffies.
Andy, Arjan,
Ok, I got it now. Well, after reboot, I ran stat() and since the info
has to come from disk, now the nanosec returned is zero!
Thanks for all your help.
Jeff.