LWN：多精度时间戳的再思考！

关注

转载 2023-10-24 13:31:10 667 阅读 AI 写同款· GEO 优化 ›

【教育信息化】基于Java+Vue的微证书可信验证系统设计：职业技能成果数字化管理与防伪溯源项目介绍基于java+vue的职业技能微证书颁发与可信验证系统设计与实现（含模型描述及部分示例代码）内容概要：本文介绍了一个基于Java和Vue的职业技能微证书颁发与可信验证系统的设计与实现，旨在解决传统职业证书管理中存在的信息分散、验证困难、易篡改、互认难等问题。系统通过构建统一的微证书业务管理体系，采用SHA-256摘要算法和RSA数字签名技术保障证书内容完整性与签发主体可信性，并结合二维码实现便捷的社会化验证。平台涵盖证书全生命周期管理，支持学习成果积累、能力画像构建及跨机构成果互认，具备完整的前后端分离架构与安全机制，适用于教育、培训与企业人力资源场景。; 适合人群：具备Java与Vue开发基础的软件工程师、高校计算机相关专业学生、职业教育信息化研究人员以及企业HR技术平台开发者。; 使用场景及目标：①实现职业技能微证书的数字化签发与防伪验证；②构建学习者个人能力档案，支持岗位匹配与人才评价；③推动教育机构、行业协会与企业间的技能成果互认与数据共享；④作为毕业设计或企业级认证平台的技术参考原型。; 阅读建议：此资源包含系统模型描述与核心代码示例，建议结合Spring Boot、MyBatis-Plus、JWT、Redis等技术栈进行实践，重点关注证书摘要生成、数字签名验证、权限控制与数据安全设计，并可通过提供的数据生成代码模拟真实业务场景进行测试。立即下载

关注了就能看到更多这么棒的文章哦～

Rethinking multi-grain timestamps

By Jonathan Corbet
October 9, 2023
ChatGPT translation
https://lwn.net/Articles/946394/

在 6.6 合并窗口期间添加到主线内核（mainline kernel）的一个重大功能就是多粒度的时间戳（multi-grain timestamp）。它允许内核有选择性地以更高精度来存储文件修改时间，而不会影响性能。不幸的是，这个特性还引发了一些令人意外的性能回退，因此很快就被撤出了内核。我们来看一下这个功能出了什么问题，以及相关开发人员计划如何继续下一步，会对大家有所启发。

文件系统里维护了若干时间戳，有的用来记录此文件的修改时间、有的记录元数据（metadata）更改时间，有的是访问时间（尽管通常出于性能原因关闭了访问时间的更新功能）。这些时间戳的分辨率相对较粗糙，以毫秒为单位；对于这些信息的通常用户来说足够好了。然而，在某些情况下需要更高的分辨率；一个突出的例子就是通过 NFS 传送文件。现代 NFS 协议可以积极地缓存文件内容以提高性能，但必须在底层文件被修改时丢弃掉这些缓存。通过修改时间戳来通知客户端进行修改是一种方式，但这仅在时间戳的分辨率足够高，可以反映频繁更改时才有效。

理论上，以更高分辨率记录时间戳是很简单的，只要文件系统有额外的数据空间。然而，更高分辨率数据带来的负担也是一个问题；低分辨率时间戳变化相对不频繁，而更频繁变化的时间戳必然导致更频繁对文件系统进行写回。这会增加 I/O 速率，尤其是对于带有日志记录功能的文件系统，其中每个元数据的更新也必须通过日志传递。增加精度的成本是显著的，尤其是如果因为一些几乎永远不会使用更高精度的数据而增加的成本更加不受欢迎。

解决方案就是多粒度时间戳，也就是只有在确实有人在关注的情况下才会记录文件的更高精度时间戳。通常情况下，时间戳数据仅以当前的相对低精度存储，这意味着可以跳过对频繁写入的文件的许多元数据的更新。然而，如果有人（例如一个进程或内核 NFS 服务器）查询特定文件的修改时间，那么时间戳字段中通常不使用的bit将被设置，用来记录查询发生过这个事实。后续的时间戳更新将以高精度执行，因为认为该文件的修改时间现在很受关注。只要有人继续查询该文件的修改时间，那么内核将继续以高分辨率更新该时间。

这就是在 6.6 版本中合并了的功能。问题在于，这个算法可能会对两个文件的相对修改时间产生误导性的结果。想象以下序列的事件：

写入 file1 。
查询 file2 的修改时间。
写入 file2 。
再次查询 file2 的修改时间。
再次写入 file1 。
查询 file1 的修改时间。

在这个序列之后，在步骤 6 中获取的 file1 的修改时间应该比 file2 的时间晚 —— 毕竟它是最后一个被写入的文件。但是，由于它的修改时间没有被查询，因此修改时间戳将以低分辨率存储。与此同时，由于存在关于 file2 的查询（尤其是步骤 2），其修改时间戳（在步骤 3 中设置并在步骤 4 中查询）将使用更高分辨率。这可能导致 file2 看起来已经在 file1 之后被更改，与实际发生的情况相反。这进而可能会使像 make 这样非常关心文件的相对修改时间的程序感到困惑。

一旦明确了存在这个问题，也就清楚了多粒度时间戳无法以其初始形式在 6.6 版本中发布。人们考虑了各种选择，包括将该特性隐藏在mount选项中，或者暂时禁用该功能。然而，正如 Christian Brauner 所描述的那样，最终决定是完全撤销该功能：

“在讨论各种修复方案时，决定重新审视问题，最终探索一种只将这种精细的时间戳内部暴露给 NFS，而不会暴露给用户空间的解决方案。
由于有多种解决方案正在讨论中，所以此处要做的现实工作不是修复或禁用它，而是干脆撤销它。”

该功能已经在 6.6-rc3 版本中被撤销（revert）。

接下来可能会看到 Jeff Layton 提出的这组patch，他是多粒度时间戳相关工作的作者。这组patch首先将底层机制添加到内核中，以便可以像以前一样选择性地存储高精度时间戳。时间戳在报告给用户空间之前会被精确地截断，因此高分辨率在虚拟文件系统层之外是不可见的。这应该可以防止上面描述的问题。

该系列还包括对 XFS 文件系统的更改，当与 NFS 配合使用时，该文件系统在需要时最能受益于高精度时间戳（其他流行的文件系统已经实现了 "change cookie" 支持，用来提供 NFS 客户端需要的关于何时丢弃缓存的信息）。通过这个改动，XFS 将使用时间戳信息来创建自己的 NFS change cookie；更高的精度就可以确保文件内容更改时会修改 cookie。

Layton 表示希望看到这些改动可以在 6.7 版本中合并。它们已经合入了虚拟文件系统这个git分支中，并目前在 linux-next 中也存在，所以看来很可能会这样发生。如果是这样的话，高分辨率的时间戳将不像最初预想的那样广泛可用，但实际上没有迹象表明用户空间需要这种分辨率；Linus Torvalds 对这种精度是不是必要的或者说有用的持有一定的批评态度。但最迫切的问题 —— 为 NFS 提供准确的更改信息 —— 最终希望能已经被解决了。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～

format,png