From: Neil Brown <neilb@cse.unsw.edu.au>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Nanosecond resolution for stat(2)
Date: Tue, 24 Sep 2002 15:13:37 +1000 [thread overview]
Message-ID: <15759.62593.58936.153791@notabene.cse.unsw.edu.au> (raw)
In-Reply-To: message from Andi Kleen on Monday September 23
On Monday September 23, ak@muc.de wrote:
>
> The kernel internally always keeps the nsec (or rather 1ms) resolution
> stamp. When a filesystem doesn't support it in its inode (like ext2)
> and the inode is flushed to disk and then reloaded then an application
> that is nanosecond aware could in theory see a backwards jumping time.
> I didn't do anything anything against that yet, because it looks more
> like a theoretical problem for me. If it should be one in practice
> it could be fixed by rounding the time up in this case.
Would it make sense, when loading a time from disk, for the low order,
non-stored bits of the time to be initialised high rather than low.
i.e. to 999,999,999 rather than 0.
This way time stamps would never seem to jump backwards, only
forwards, which seems less likely to cause confusion and will mean that a
change is not missed (I'm thinking NFS here where cache correctness
depends heavily on mtime).
Also, would it make sense, for filesystems that don't store the full
resolution, to make that forward jump appear as early as
possible. i.e. if the mtime (ctime/atime) is earlier than the current
time at the resoltion of the filesystem, then make the mtime appear to
be what it would be if reloaded from storage... Maybe an example
would help.
Assuming an internal resolution on 1millisecond (to save on digits)
and a stored resolution of 1 second
time change is made Apparent timestamp
23.100 X 23.100
23.200 23.100
23.300 X 23.300
23.500 X 23.500
23.900 23.500
24.001 23.999
25.000 23.999
Thus the only incorrect observation that an application can make is
that there is an extra change at the end of a second when other
changes were made. I think this is better than an apparent change
suddenly becoming visible many minutes after the time of that apparent
change, and definately better than a timestamp moving backwards.
NeilBrown
next prev parent reply other threads:[~2002-09-24 5:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-23 21:48 Nanosecond resolution for stat(2) Andi Kleen
2002-09-24 4:05 ` Andrew Pimlott
2002-09-24 4:35 ` Mark Mielke
2002-09-24 5:21 ` Andreas Dilger
2002-09-24 5:13 ` Neil Brown [this message]
[not found] <20020923214836.GA8449@averell.suse.lists.linux.kernel>
[not found] ` <20020924040528.GA22618@pimlott.net.suse.lists.linux.kernel>
2002-09-24 12:10 ` Andi Kleen
[not found] ` <15759.62593.58936.153791@notabene.cse.unsw.edu.au.suse.lists.linux.kernel>
2002-09-24 12:21 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15759.62593.58936.153791@notabene.cse.unsw.edu.au \
--to=neilb@cse.unsw.edu.au \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).