OpenBSD 上的 GEFS：早期预览

[ 列表中的上一个 ] [ 列表中的下一个 ] [ 线程中的上一个 ] [ 线程中的下一个 ] 列表：openbsd-tech 主题：OpenBSD 上的 GEFS：非常早期的预览 来自：ori () eigenstate ！组织日期：2026-09-15 15:45:05 消息 ID：EBB049B251DCF60A8C9A0575F6FC7DC9 () 本征态！ org [下载原始消息或正文] 在有人问之前：我*不*建议将其放在树中一段时间​​。它是什么 ---------- 因此，正如人们可能在 EuroBSD 上看到的那样，我得到了在 OpenBSD 上运行的 GEFS 的一个粗糙的、有缺陷的、充满问题的预览。该端口尚未准备好用于生产，目前预计会丢失数据，尤其是在出错时。然而，该端口已经达到了（除了一些例外）剩余问题被合理理解的状态，人们可以戳它们。对于那些没有看过我的演讲的人来说，GEFS 是一个新的、崩溃安全的、快照的、写时复制的 FS，是我为 9front 编写的，我正在将其迁移到 OpenBSD。文件系统在这里有完整的描述：https://orib.dev/gefs.pdf 目前内核中的代码不足 9,000 行，不过我预计它会随着时间的推移而增长一点，因为有很多内容丢失了。移植 ------- 我将其视为一个适当的内核文件系统，它可以在 Plan 9 和 OpenBSD 之间保持数据结构和繁琐的代码相当同步，但代码本身是复制和粘贴的。我的目标是它将继续保持一致，以便可以共享修复程序，但是两种环境的要求意味着代码可能不会被移植，并且尝试插入某些抽象层似乎是一个坏主意。问题 -------- 所以，IMO，剩下的最大问题是： 一致性协议：这对我来说是一个很大的未知数；对超级块的写入需要在快照中的所有写入之后进行，但只要在块击中磁盘之后写入，它就是安全的。还有一些针对写入顺序从 9Front 向后移植的修复。错误处理和移植脑损伤：错误处理大部分被注释掉了。我将不得不一点一点地检查错误处理路径并小心地转换它；我在 9front 上采用的错误处理方法对于 OpenBSD 来说是不可接受的。还有其他一些事情，例如使用的某些全局变量会一次阻止多个挂载。用户空间工具：至少，我认为告诉人们在虚拟机中启动 9front 来创建或 fsck 并不是一个好的长期解决方案。快照管理和相关的 ioctl 也将位于此处。 Posix 细节：移植的系统不是 posix 系统，因此可能有很多地方我们没有完全得到正确的约束。回归：Plan 9 有一个小型测试套件。OpenBSD 没有。硬链接：易于实现，但需要逐个文件进行引用计数。 Kqueue：易于实现，但需要逐个文件进行引用计数。 NFS：有一些丑陋的钩子，不知道需要什么来添加它们。其他缺失的部分：诸如引导加载程序支持、添加引导环境、配额和其他细节等；这在名单上排得很靠后。特别是，配额将允许 LLVM 继续尝试增长到已知宇宙的大小，而无需我们预先分配该大小的 /usr/obj。我确信我已经忘记了一些。现在：我不打算修复 KNF；当事情发生变化时，我将开始将它们移过来，但我更愿意让代码与原始代码更接近，直到它更接近为上游做好准备。还有一些独立于 9front 和 OpenBSD 的非致命问题，例如大文件删除速度慢；我有改进它们的想法。获取它 ---------- 作为一个补丁：https;//orib.dev/gefs.diff git 存储库隐藏在shihub 上，而且服务器很小，如果人们从中克隆新的存储库，就会超载。相反，从 github 获取初始存储库的副本，然后仅提取更新。 # 首先，从其他地方获取上游的副本 git clone https://github.com/openbsd/src cd src # 现在，添加我的服务器，并获取差异 git Remote add gefs git://shithub.us/ori/openbsd git fetch gefs git checkout -b gefs gefs/gefs 注意，我会偶尔重新调整并强制推送分支，以便跟上当前的openbsd；提交 ID 将会改变。 [列表中的上一个] [列表中的下一个] [线程中的上一个] [线程中的下一个] 配置 |关于 |新闻 |添加列表 |由 KoreLogic 赞助