From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757738AbcBDVCv (ORCPT ); Thu, 4 Feb 2016 16:02:51 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:55213 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965422AbcBDVCl (ORCPT ); Thu, 4 Feb 2016 16:02:41 -0500 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Gregory Farnum , "Theodore Ts'o" , Sage Weil , Zheng Yan , Dave Chinner , linux-kernel , "Yan, Zheng" , Deepa Dinamani , Alex Elder , linux-fsdevel@vger.kernel.org, Ilya Dryomov , ceph-devel 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 Message-ID: <2730461.dq5ziXmlM8@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1454479670-8204-1-git-send-email-deepa.kernel@gmail.com> <3114558.FPEUoEgqxL@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:87gmLExXZBmlFocPAzLTCb5QK6yGNJg5YGjlE7pPoDcjf+ZDESS ZWBSzOLCtxo3adaDwvfT1TEMk5MNPUnLUluGKGu29uHcDp/2N3ujB+NaKh+IItHOhPMILZ0 A4Kk6UhR1Aba4Sg+bLAMX1limQB4+JHdnjU8aRGFJM2VHldoYur2Ba2Xs/VHp2zwkBC6WZH o5ue/zlRmO4K2otEj38mA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NH2FkZAa6vc=:99kjAV+mE9O6k1T6BszKFC cWVMCoWTBhc67Yh1+t70/VlcBLT3QAPGcAjIcbt403IrBbAT0ZGEJjiByDWTBsiHtDrrZlooB FhonB+8u8uMbtwo0YHcKFA64QOFJNhxWee17OQ4IKDNgyd69Ti9yRFC2VcyHIV90EyUZfsNG/ ViskWqPqZMzfXp5hLmWnHI2sdM1Rw2EJ2YAUfMerSTGHZpuDq5IIh6KJeUAsNsG2n0sf/fd4c CDokgUaES2JxFsHKNvdsqgXEDOi4IKrGm+PqIbNsoq1LlWWIoiRD6P4iJJREv5GH7VD5RqLFu 4XC8BcVUm/9JO17sWbOjCY6RIqpjTMtutaIRX374Ajgrg8N076T9L2CimmgATZEMekXlmnxkO d6gr4ycC+5bpOX3dpRprFvAxHVk4eop7NmDYEefK7A5Dv4KziiSvS/q0vZwo7VjJsq8oGE5zn q9mE+gVnmmfMfLOYv6Vm3y0tJhf/YhmkKvz92hbvOLzgg+QDlYWGAvNFzb3+lFewAlNpVFzW8 3FMWR0cwRcMBvn4sXbdFJ7UqTIWFHY8+pOg0x1V+UXJW1wnkjhhO8yHq4M9/OfsGkJXbLdFbU +iVm7TgRlycaM8X+XwKcydYP0ZA43UyKYn/Mz91wfeFA7fOPbSe047kEpjlV58c3LaBWLnMGP hTF63Wcv7ZXjnPGkX7MXRWtwlC7v1Sz6UErbsJ66qwUU/k986q3byr+tByFkMAHYr0+dUhQes CfqEy4EOlFKOviuu Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 04 February 2016 07:26:51 Gregory Farnum wrote: > On Thu, Feb 4, 2016 at 5:31 AM, Arnd Bergmann wrote: > > On Thursday 04 February 2016 10:01:31 Ilya Dryomov wrote: > >> On Thu, Feb 4, 2016 at 9:30 AM, Arnd Bergmann 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