linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Pimlott <andrew@pimlott.net>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Nanosecond resolution for stat(2)
Date: Tue, 24 Sep 2002 00:05:28 -0400	[thread overview]
Message-ID: <20020924040528.GA22618@pimlott.net> (raw)
In-Reply-To: <20020923214836.GA8449@averell>

On Mon, Sep 23, 2002 at 11:48:36PM +0200, Andi Kleen 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.

I assume you mean "theoretical" that an application would care, not
that it would happen.  (Unless I misunderstand, it is nearly
guaranteed to happen every time an inode is evicted after a
[mac]time update.)

I fear that there are applications that will be harmed by any
spurious change in [mac]time, even if it's not backwards.  Apps that
trigger on any change in mtime may trigger twice for every change.
Eg, I suspect there is some scenario in which an rsync-like
application that supports nanoseconds could suffer (just in
performance, but still).

> If it should be one in practice 
> it could be fixed by rounding the time up in this case.

This would mean that even "legacy" programs that only use second
resolution would be affected, which seems worse.  At least programs
that recognize the nanosecond field are more likely to know about
the issue.

Andrew

  reply	other threads:[~2002-09-24  4:13 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 [this message]
2002-09-24  4:35   ` Mark Mielke
2002-09-24  5:21     ` Andreas Dilger
2002-09-24  5:13 ` Neil Brown
     [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=20020924040528.GA22618@pimlott.net \
    --to=andrew@pimlott.net \
    --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).