Linux 5.10 将解决 2038 年问题,延长至 2486 年

白开水不加糖
 白开水不加糖
发布于 2020年10月22日
收藏 3

即将发布的 Linux 5.10 或将包括针对 2038 年问题(又称 “Y2038” 或 “Unix Y2K” 问题)的进一步修复。Linux 内核邮件列表显示,Oracle 文件系统开发人员 Darrick J. Wong 已提交了有关 XFS 文件系统的代码,其中添加了一个新功能以支持时间戳,直至 2486 年。

2038 年问题与千年虫问题类似,它可能会导致某些软件在 2038 年 1 月 19 日 3 时 14 分 07 秒之后无法正常工作。届时,在大部分 32 位操作系统上,依据 “time_t” 标准,时间将会“绕回”且在内部被表示为一个负数,并造成程序无法工作,因为它们无法识别 2038 年,而可能会跳回 1970 年或 1901 年。

Phoronix 所述,XFS 支持了两项新的 on-disk meta-data 功能,具体为:

  • 分配组中现在会记录 inode btrees 的大小。这样做是为了增加冗余检查,并允许更快的安装时间。
  • 支持直到 2486 年的时间戳。这个“大时间戳”功能是对其时间戳和 inode 编码功能进行重构,以将时间戳作为 64 位纳秒计数器进行处理,并通过移位来增加有效大小。现在,这使 XFS 可以很好地克服 2038 年的问题(在那里,以秒为单位存储自 1970 年以来的时间将不再适合有符号的 32 位整数,因此无法环绕)到现在的 2486 年。使用以下命令创建新的XFS文件系统:启用 bigtime 允许的时间戳范围是 1901 年 12 月至 2486 年 7 月,而不是 1901 年 12 月至 2038 年 1 月。为了保持向后兼容,默认情况下当前未启用 big timestamps 功能。

此外,今年年初,Linux Kernel 5.6 的开发者也早就准备好着手解决将在下一个十年到来的 2038 年问题。Linux 5.6 也是第一个为 32 位系统准备运行到 2038 年之后的主线内核。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Linux 5.10 将解决 2038 年问题,延长至 2486 年
加载中

精彩评论

W
WindSpeed
机器人经典三连问。老机器人了
Feng_Yu
Feng_Yu
如果你的路由的寿命真的能长到2038年还能用的地步,那就别瞎操心了
乳沟
乳沟
这个问题该解决了,毕竟只有18年了!现在解决,估计到时候还得有一些老系统瘫痪!
欧阳春晖
欧阳春晖
几乎每次都是扩大精度,要不就是调整逻辑绕过问题
欧阳春晖
欧阳春晖
千年虫的bug是无法被完美解决的,和卫星周期数归0一样,只能隔一段时间来一个补丁

最新评论(37

livem
livem
2486年还有 Linux 吗
欧阳春晖
欧阳春晖
回复 @120011676 : 扩一下,很多地方都要改的,要增加特性的,还有兼容性问题在这里要考虑
欧阳春晖
欧阳春晖
回复 @120011676 : 你告诉我如何自动扩?和cpu位数关系很大
120011676
120011676
回复 @欧阳春晖 : 修复程序就不能写个快不够了的时候,自动扩,我上次这样搞,这次这样搞,下次这样搞,次次这样搞,可以做到嘛
欧阳春晖
欧阳春晖
回复 @120011676 : 这次能修复是cpu从32位扩展到了64位的结果,所以设计64位时间戳可以让精度容量提高一倍
欧阳春晖
欧阳春晖
回复 @120011676 : 我已经说的很清楚了,严格来说,这根本不是一个bug,并不属于设计和实现错误,怎么修复?这是因为计算机精度是有限的
欧阳春晖
欧阳春晖
回复 @120011676 : 不行,每次都只能减缓问题
120011676
120011676
不就修复了
120011676
120011676
回复 @欧阳春晖 : 现在能不能修复下下次的出现?下下下次呢?下下下下次呢?
墨子煜
墨子煜
400多年后
返回顶部
顶部