LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] nanosecond filesystem support???
@ 2007-02-13  8:38 Jeff Chua
  2007-02-13  8:42 ` Arjan van de Ven
  2007-02-13  8:52 ` Andi Kleen
  0 siblings, 2 replies; 4+ messages in thread
From: Jeff Chua @ 2007-02-13  8:38 UTC (permalink / raw)
  To: Andi Kleen; +Cc: lkml, Arjan van de Ven, Miquel van Smoorenburg, Linus Torvalds


On 2/12/07, Andi Kleen <ak@suse.de> 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;
  	}


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nanosecond filesystem support???
  2007-02-13  8:38 [PATCH] nanosecond filesystem support??? Jeff Chua
@ 2007-02-13  8:42 ` Arjan van de Ven
  2007-02-13  8:52 ` Andi Kleen
  1 sibling, 0 replies; 4+ messages in thread
From: Arjan van de Ven @ 2007-02-13  8:42 UTC (permalink / raw)
  To: Jeff Chua; +Cc: Andi Kleen, lkml, Miquel van Smoorenburg, Linus Torvalds

On Tue, 2007-02-13 at 16:38 +0800, Jeff Chua wrote:
> On 2/12/07, Andi Kleen <ak@suse.de> 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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nanosecond filesystem support???
  2007-02-13  8:38 [PATCH] nanosecond filesystem support??? Jeff Chua
  2007-02-13  8:42 ` Arjan van de Ven
@ 2007-02-13  8:52 ` Andi Kleen
  2007-02-13  9:09   ` Jeff Chua
  1 sibling, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2007-02-13  8:52 UTC (permalink / raw)
  To: Jeff Chua; +Cc: lkml, Arjan van de Ven, Miquel van Smoorenburg, Linus Torvalds


> 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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nanosecond filesystem support???
  2007-02-13  8:52 ` Andi Kleen
@ 2007-02-13  9:09   ` Jeff Chua
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff Chua @ 2007-02-13  9:09 UTC (permalink / raw)
  To: Andi Kleen; +Cc: lkml, Arjan van de Ven, Miquel van Smoorenburg, Linus Torvalds

On 2/13/07, Arjan van de Ven <arjan@infradead.org> wrote:
> it was there to avoid the following situation:
> on disk it's still in seconds


On 2/13/07, Andi Kleen <andi@firstfloor.org> 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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-02-13  9:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-13  8:38 [PATCH] nanosecond filesystem support??? Jeff Chua
2007-02-13  8:42 ` Arjan van de Ven
2007-02-13  8:52 ` Andi Kleen
2007-02-13  9:09   ` Jeff Chua

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).