On Thursday 04 February 2016 07:26:51 Gregory Farnum wrote: > On Thu, Feb 4, 2016 at 5:31 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Thursday 04 February 2016 10:01:31 Ilya Dryomov wrote: > >> On Thu, Feb 4, 2016 at 9:30 AM, Arnd Bergmann <arnd@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
