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