Re: [Y2038] [PATCH 09/10] fs: ceph: Replace CURRENT_TIME by ktime_get_real_ts()

From: Arnd Bergmann <arnd@arndb.de>
To: y2038@lists.linaro.org
Cc: Gregory Farnum <gfarnum@redhat.com>,
	"Theodore Ts'o" <tytso@mit.edu>, Sage Weil <sage@redhat.com>,
	Zheng Yan <ukernel@gmail.com>, Dave Chinner <david@fromorbit.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Yan, Zheng" <zyan@redhat.com>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Alex Elder <elder@linaro.org>,
	linux-fsdevel@vger.kernel.org, Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: [Y2038] [PATCH 09/10] fs: ceph: Replace CURRENT_TIME by ktime_get_real_ts()
Date: Thu, 04 Feb 2016 22:02:28 +0100	[thread overview]
Message-ID: <2730461.dq5ziXmlM8@wuerfel> (raw)
In-Reply-To: <CAJ4mKGa0NDGNOPTg_MyE_B7BpPQLQ7JfiiBFuZ5t-t57VNihRQ@mail.gmail.com>

On Thursday 04 February 2016 07:26:51 Gregory Farnum wrote:
> On Thu, Feb 4, 2016 at 5:31 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 04 February 2016 10:01:31 Ilya Dryomov wrote:
> >> On Thu, Feb 4, 2016 at 9:30 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > A lot of other file systems (jfs, jffs2, hpfs, minix) apparently
> > prefer the 1970..2106 interpretation of time values.
> >
> >> The plan is to eventually switch to a 64-bit tv_sec and
> >> tv_nsec, bump the version on all the structures that contain it and add
> >> a cluster-wide feature bit to deal with older clients.  We've recently had
> >> a discussion about this, so it may even happen in a not so distant future, but
> >> no promises
> >
> > Ok. We have a (rough) plan to deal with file systems that don't support
> > extended time stamps in the meantime, so depending on user preferences
> > we would either allow them to be used as before with times clamped
> > to the 2038 overflow date, or only mounted readonly for users that want
> > to ensure their systems can survive without regressions in 2038.
> 
> I dug up the email conversation, about it, although I think Adam has
> done more work than it indicates:
> http://www.spinics.net/lists/ceph-devel/msg27900.html. I can't speak
> to any kernel-specific issues but this kind of transition while
> maintaining wire compatibility with older code is something we've done
> a lot; it shouldn't be a big deal even in the kernel where we're
> slightly less prolific with such things. 

On the kernel side, the interesting part is to figure out whether
the other end can support the new format or not, and setting the limit
in the superblock accordingly. Once you have determined that both
sides support the extended timestamps, sending a timestamp beyond 2038
must not fail or cause incorrect data.

On the wire protocol, you could consider extending the timestamps in
the same way as ext4, as you already have nanosecond timestamps, and
you can use the upper two bits of the nanoseconds to extend the seconds
field to 34 bits, giving you a range of valid times between 1902
and 2446, though if you have to make an incompatible change anyway,
going to 64 bit is easier.

	Arnd