From: Theodore Ts'o <tytso@mit.edu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
lftan@altera.com, hch@infradead.org, john.stultz@linaro.org,
"H. Peter Anvin" <hpa@zytor.com>,
linux-fsdevel@vger.kernel.org, geert@linux-m68k.org,
tglx@linutronix.de, xfs@oss.sgi.com, joseph@codesourcery.com
Subject: Re: [RFC 11/32] xfs: convert to struct inode_time
Date: Mon, 2 Jun 2014 09:07:00 -0400 [thread overview]
Message-ID: <20140602130700.GC14276@thunk.org> (raw)
In-Reply-To: <15496653.1vSv1RUCC0@wuerfel>
Yes, there are some ongoing dicussions about changing the post-2038
encoding of the timestamp in ext4, which is why this hasn't been fixed
yet. The main thing that's been missing is time for me to review the
patches, and a good way of writing regression tests that will work (or
at least not fail) on build environments with a 32-bit time_t and
32-bit-only capable versions of functions such as gmtime(3).
And given current discussions, I may want to think about some kind of
superblock flag to allow the use of a 32-bit unsigned encoding for
file systems using a 128-byte inode, with a way of setting that flag
after scanning the file system to make sure there are no times that
are previous to January 1, 1970. (Or more generally, allow any epoch
to be defined using a 64-bit time_t offset stored in the superblock...)
Cheers,
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-02 13:07 UTC|newest]
Thread overview: 71+ 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 11/32] xfs: convert to struct inode_time Arnd Bergmann
2014-05-31 0:37 ` Dave Chinner
2014-05-31 0:41 ` H. Peter Anvin
2014-05-31 1:14 ` Dave Chinner
2014-05-31 1:22 ` H. Peter Anvin
2014-05-31 5:54 ` Dave Chinner
2014-05-31 8:41 ` H. Peter Anvin
2014-05-31 15:46 ` Nicolas Pitre
2014-06-01 19:56 ` Arnd Bergmann
2014-06-01 20:26 ` H. Peter Anvin
2014-06-02 11:02 ` Arnd Bergmann
2014-06-02 1:36 ` Nicolas Pitre
2014-06-02 2:22 ` Dave Chinner
2014-06-02 7:09 ` Geert Uytterhoeven
2014-06-02 10:56 ` Arnd Bergmann
2014-06-02 11:57 ` Theodore Ts'o
2014-06-02 12:38 ` Arnd Bergmann
2014-06-02 13:15 ` Theodore Ts'o
2014-06-02 12:52 ` Arnd Bergmann
2014-06-02 13:07 ` Theodore Ts'o [this message]
2014-06-02 15:01 ` Arnd Bergmann
2014-06-02 14:52 ` H. Peter Anvin
2014-06-02 15:04 ` Chuck Lever
2014-06-02 15:31 ` Theodore Ts'o
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
2014-06-01 0:39 ` Dave Chinner
2014-06-02 14:00 ` Joseph S. Myers
2014-05-31 15:37 ` Arnd Bergmann
2014-06-01 0:24 ` Dave Chinner
2014-06-02 0:28 ` Dave Chinner
2014-06-02 11:35 ` Roger Willcocks
2014-06-02 11:43 ` Arnd Bergmann
2014-06-03 0:32 ` Dave Chinner
2014-06-03 7:33 ` Arnd Bergmann
2014-06-03 8:41 ` Dave Chinner
2014-06-03 9:16 ` 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
[not found] ` <6347520.8jMPlVsFjM@wuerfel>
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
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=20140602130700.GC14276@thunk.org \
--to=tytso@mit.edu \
--cc=arnd@arndb.de \
--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=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