TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

XFS File-System with Linux 5.10 Punts Year 2038 Problem to the Year 2486

166 点作者 programd超过 4 年前

11 条评论

tytso超过 4 年前
The reason why ext4 and xfs both use nanosecond resolution is because in the kernel the high precision time keeping structure is the timespec structure (which originally was defined by POSIX). That uses tv_sec and tv_nsec. Certainly in 2008, when ext4 was declared &quot;stable&quot;, the hardware of the time was nowhere near having the necessary resolution to give us nanosecond accuract. However, that&#x27;s not really the point. We want to be able to store an arbitrary timespec value, encode it in the file system timestamp, and then decode it back to a bit-identical timespec value. So that&#x27;s why it makes sense to use at least a nanosecond granularity.<p>Why not use a finer granularity? Because space in the on-disk inode structure is precious. We need 30 bits to encode nanoseconds. That leaves an extra two bits that can be added to 32 bit &quot;time in seconds since the Unix epoch&quot;. For full backwards compatibility, where a &quot;negative&quot; tv_sec corresponds to times before 1970, that gets you to the 25th century. If we <i>really</i> cared, we could add an extra 500 years by stealing a bit somewhere from the inode (maybe an unused flag bit, perhaps --- but since there are 4 timestamps in an inode, you would need to steal 4 bits for each doubling of time range). However, there is no guarantee that ext4 or xfs will be used 400-500 years from now; and if it <i>is</i> being used, it seems likely that there will plenty of time to do another format bump; XFS has had 4 incompatible fomat bumps in the last 27 years. ext2&#x2F;ext3&#x2F;ext4 has been around for 28 years, and depending on how you count, there has been 2-4 major version bumps (we use finer-grained feature bits, so it&#x27;s a bit hard to count). In the next 500 years, we&#x27;ll probably have a few more. :-)
评论 #24816346 未加载
freedomben超过 4 年前
It&#x27;s tempting to think that 2038 is a long way off, so who cares, but I still regularly encounter systems that have been in prod for 20+ years. 2038 is only 18 years away! If you&#x27;re building systems today, it&#x27;s worth thinking about how these kinds of issues may affect things. You may still be around then anyhow, so your future self may thank you.
评论 #24813745 未加载
评论 #24813655 未加载
评论 #24814229 未加载
评论 #24813573 未加载
评论 #24817357 未加载
评论 #24814776 未加载
评论 #24819468 未加载
评论 #24813970 未加载
kortex超过 4 年前
So what&#x27;s the next step? Elsewhere in this thread, picoseconds were mentioned and that seems plausibly useful, so that&#x27;s 10 bits. And it would be nice to avoid &quot;year xyz&quot; problems, so maybe we could have a coding region of say 2 bits to encode 4 overlapping epochs to allow rolling updates. That seems to imply at least a 10-byte or 12-byte time.<p>I don&#x27;t see any way in which that could easily fit with POSIX time types, unless you keep the existing 32-bit time_t and tv_nsecs fields and tack on two 16-bit fields for extending precision in either direction. But ISO C allows time_t to be a floating point number, which opens a few doors.<p>What about UTF-8 style variable length times? Would that be too messy?<p>Edit: looks like most 64-bit OSes are already or are switching to 64-bit time_t. So that solves half the problem, but no picoseconds just yet. I guess that&#x27;s what int64 or float64&#x2F;80 is for.
评论 #24815965 未加载
bratao超过 4 年前
I´m impressed by the amount of new features that has been coming out XFS. The benchmarks (<a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=linux-58-filesystems&amp;num=4" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=linux-58...</a>) also confirms that is (one of) the best a mature FS around.
评论 #24816402 未加载
评论 #24815754 未加载
bloak超过 4 年前
There&#x27;s a better explanation here, though I still don&#x27;t understand &quot;34-bit unsigned second counter right shifted two bits&quot; and &quot;(((2^34-1) + (2^31-1)) &amp; ~3)&quot;:<p><a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;829314&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;829314&#x2F;</a>
评论 #24813969 未加载
评论 #24813823 未加载
评论 #24813801 未加载
jart超过 4 年前
This is what happens when your data structures declare year zero like pol pot. Unfortunately if we wanted to be scientific we&#x27;d probably need something like 3000 bit timestamps to do planck time until heat death of the universe. XFS could have lasted the better part of the stelliferous era if they had chosen struct timespec, but even that has the problematic nanosecond granularity limitation. It&#x27;s not the stone age and seconds have a very clear definition these days in terms of the number of hyperfine transitions of caesium, so I would have hoped new data structures would at least choose that.
评论 #24814233 未加载
评论 #24815128 未加载
评论 #24815811 未加载
评论 #24814148 未加载
trhway超过 4 年前
one way for a generational ship to fail.
评论 #24813436 未加载
n00ri超过 4 年前
interresting
ncmncm超过 4 年前
Just interpreting time as unsigned would take them to 2106. Probably there would be other filesystems to use before then.<p>There are exactly zero XFS filesystem files created before 1970, so there is no need to represent those times in a filesystem.<p>I seriously wonder what makes this basic fact so hard for so many people to process. If you have a clue, please do explain.
评论 #24814578 未加载
rvr_超过 4 年前
I really wish people (and redhat) just stop using XFS altogether. I have seen it break multiple times with two different scenarios: 1) Backup system with external media (usb3) on XFS. The USB link goes down, the kernel panics inside some XFS code. Hard reset needed. 2) Production system with &lt;1M files being actively read by apache http. Hot updating this folder via rsync randomly panics the system.<p>After a couple of times you just migrate to something sane, like ext4, and everything works flawlessly.
评论 #24814877 未加载
评论 #24816669 未加载
评论 #24818216 未加载
评论 #24815791 未加载
danschumann超过 4 年前
Okay, if that&#x27;s a punt, the ball has left the stadium, left the parking lot, narrowly avoids hitting skyscrapers downtown, on it&#x27;s way to landing safely in a park n ride outside of town, where it bounces a few times before coming to a stop, but not before it taps into a car, setting off an alarm, which happens to be a fans car who bussed in, trying to save on traffic, but will be woefully disappointed to find his car dead, only to have his spirits lifted when he finds the game ball, only slightly charred from breaking the sound barrier, and a jump from his crush who went to the game with him, and then she helped him with his dead battery, heyo!