From: "Theodore Ts'o" <tytso@mit.edu>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Dave Chinner <david@fromorbit.com>,
LKML Kernel <linux-kernel@vger.kernel.org>,
linux-arch@vger.kernel.org, joseph@codesourcery.com,
john.stultz@linaro.org, Christoph Hellwig <hch@infradead.org>,
tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
xfs@oss.sgi.com,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [RFC 11/32] xfs: convert to struct inode_time
Date: Mon, 2 Jun 2014 11:31:24 -0400 [thread overview]
Message-ID: <20140602153124.GH30598@thunk.org> (raw)
In-Reply-To: <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com>
On Mon, Jun 02, 2014 at 11:04:23AM -0400, Chuck Lever wrote:
> I’m wondering what should be done about NFS. A solution for NFS should
> match any scheme that is considered for local file systems, IMO.
>
> An alternative would be to “cap” the timestamps transmitted via NFSv3 by
> Linux, so that a pre-epoch timestamp is transmitted as zero, and a large
> timestamp is transmitted as UINT_MAX.
I wonder if it would make sense to try to promulgate via the Austin
group, and possibly the C standards committee the concept of a bit
pattern (that might commonly be INT_MAX or UINT_MAX) that means "time
unknown", or "time indefinite" or "we couldn't encode the time".
We would then teach gmtime(3) and asctime(3) to print some appropriate
message, and we could teach programs like find (with the -mtime)
option, make, tmpwatch, et. al., that they can't make any presumption
about the comparibility of any timestamp which has a value of
TIME_UNDEFINIED.
It would be problematic for time(2) or gettimeofday(2) to return
TIME_UNDEFINED, since there are programs that care about time ticking
forward, but I could imagine a new interface which would be permitted
to return a flag indicating that we don't know the current time
(because the CMOS battery had run down, etc.) so instead we're going
to be counting the number of seconds since the system was booted.
- Ted
next prev parent reply other threads:[~2014-06-02 15:31 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 20:01 [RFC 00/32] making inode time stamps y2038 ready Arnd Bergmann
2014-05-30 20:01 ` [RFC 07/32] fs/nfs: convert to struct inode_time Arnd Bergmann
2014-05-31 14:30 ` [RFC 00/32] making inode time stamps y2038 ready Vyacheslav Dubeyko
2014-06-03 12:21 ` Arnd Bergmann
2014-05-31 14:51 ` Richard Cochran
2014-05-31 15:23 ` Arnd Bergmann
2014-05-31 16:20 ` Geert Uytterhoeven
2014-05-31 18:22 ` Richard Cochran
2014-05-31 19:34 ` H. Peter Anvin
2014-06-01 4:46 ` Richard Cochran
2014-06-01 4:44 ` Richard Cochran
2014-06-02 13:52 ` Joseph S. Myers
2014-06-02 19:19 ` Arnd Bergmann
2014-06-02 19:26 ` H. Peter Anvin
2014-06-02 19:55 ` Arnd Bergmann
2014-06-02 21:57 ` H. Peter Anvin
2014-06-03 14:22 ` Arnd Bergmann
2014-06-03 14:33 ` Joseph S. Myers
2014-06-03 14:37 ` Arnd Bergmann
2014-06-03 21:38 ` Dave Chinner
2014-06-04 15:03 ` Arnd Bergmann
2014-06-04 17:30 ` Nicolas Pitre
2014-06-04 19:24 ` Arnd Bergmann
2014-06-05 0:10 ` H. Peter Anvin
2014-06-10 9:54 ` Arnd Bergmann
2014-06-02 21:02 ` Joseph S. Myers
2014-06-04 15:05 ` Arnd Bergmann
[not found] ` <8618458.1EVJCoVbkH@wuerfel>
[not found] ` <alpine.LFD.2.11.1406012121430.17310@knanqh.ubzr>
[not found] ` <4178301.j9kWdGCRLC@wuerfel>
2014-06-02 15:04 ` [RFC 11/32] xfs: convert to struct inode_time Chuck Lever
2014-06-02 15:31 ` Theodore Ts'o [this message]
2014-06-02 17:12 ` H. Peter Anvin
2014-06-02 18:50 ` Arnd Bergmann
2014-06-02 22:29 ` Theodore Ts'o
2014-06-02 22:32 ` H. Peter Anvin
2014-06-02 23:32 ` Theodore Ts'o
2014-06-02 23:33 ` H. Peter Anvin
2014-06-03 13:09 ` Roger Willcocks
2014-06-02 18:52 ` Arnd Bergmann
2014-06-02 18:58 ` Roger Willcocks
2014-06-02 19:04 ` Chuck Lever
2014-06-02 19:10 ` Arnd Bergmann
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=20140602153124.GH30598@thunk.org \
--to=tytso@mit.edu \
--cc=arnd@arndb.de \
--cc=chuck.lever@oracle.com \
--cc=david@fromorbit.com \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=john.stultz@linaro.org \
--cc=joseph@codesourcery.com \
--cc=lftan@altera.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=tglx@linutronix.de \
--cc=xfs@oss.sgi.com \
/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).