GEFS on OpenBSD: A very early preview

查看原文 / View Original 编辑 / Edit

GEFS on OpenBSD: A very early preview

GEFS 在 OpenBSD 上的初步预览

Before anyone asks: I am not proposing to put this in tree for a while yet. 在有人问起之前，我先说明：我目前并不打算将其合并到 OpenBSD 主线代码树中。

What is it

它是什么

So, as people may have seen at EuroBSD, I’ve got a rough, buggy, issue-filled preview of GEFS running on OpenBSD. The port is NOT ready for production, and data loss is currently expected, especially on error. However, the port has reached the state where (with some exceptions) the remaining problems are reasonably understood, and people can poke at them. 正如大家在 EuroBSD 大会上可能看到的那样，我已经让 GEFS 在 OpenBSD 上运行起来了，但目前它还处于粗糙、充满 Bug 和各种问题的预览阶段。该移植版本尚未达到生产就绪状态，目前使用可能会导致数据丢失，尤其是在发生错误时。不过，该移植工作已经达到了一定程度，除了少数例外，剩余的问题已基本明确，大家可以尝试进行测试和研究。

For those who haven’t watched my talk, GEFS is a new, crash-safe, snapshotting, copy on write FS that I wrote for 9front, and which I am in the process of moving to OpenBSD. The file system is described in full here: https://orib.dev/gefs.pdf. It’s under 9,000 lines of code in kernel at the moment, though I expect it’ll grow a bit over time, since there’s a good deal missing. 对于没看过我演讲的人，GEFS 是我为 9front 编写的一种全新的、具备崩溃安全性、支持快照和写时复制（Copy-on-Write）的文件系统，我目前正将其移植到 OpenBSD。该文件系统的详细说明请见：https://orib.dev/gefs.pdf。目前内核代码量不到 9,000 行，但我预计随着功能的完善，代码量会逐渐增加。

Porting

移植工作

I’m approaching this as a proper, in-kernel file system that keeps the data structure and fiddly code fairly in sync between Plan 9 and OpenBSD, but the code itself is copied and pasted. My goal is that it will continue to rhyme, so that fixes can be shared, but the requirements of the two environments means that the code probably won’t be ported, and trying to shove in some abstraction layer seems like a bad idea. 我将其作为一种标准的内核文件系统进行移植，在 Plan 9 和 OpenBSD 之间保持数据结构和核心逻辑的同步，但代码本身是直接复制粘贴的。我的目标是让两者保持逻辑上的相似，以便共享修复方案，但由于两个环境的需求差异，代码本身可能无法直接通用，强行引入抽象层似乎并不是一个好主意。

Problems

存在的问题

So, IMO, the biggest of the remaining problems: 在我看来，目前剩余的最大问题包括：

  • Consistency Protocol: This is the big unknown for me; A write to the superblock needs to come after all writes in the snapshot, but as long as it is written after the blocks have hit disk, it’s safe. There are also a couple of fixes to backport from 9Front on the write ordering. 一致性协议： 这是我目前最大的未知数；超级块（superblock）的写入必须在快照中的所有写入操作之后进行，只要确保在数据块落盘后再写入超级块，就是安全的。此外，还有一些来自 9Front 的关于写入顺序的修复需要反向移植。

  • Error handling and porting brain damage: Error handling is largely commented out. I’m going to have to go through the error handling paths bit by bit and convert it with care; the approach to error handling I took on 9front is not acceptable for OpenBSD. There’s a few other things, like some globals being used that would prevent more than one mount at a time. 错误处理与移植带来的问题： 错误处理代码目前大部分被注释掉了。我必须逐一检查错误处理路径并谨慎转换；我在 9front 中采用的错误处理方式并不适用于 OpenBSD。此外还有一些其他问题，例如使用了全局变量，导致无法同时挂载多个实例。

  • Userspace tools: At least, I assume that telling people to boot 9front in a VM to create or fsck is not a good long term solution. Snapshot management and the associated ioctls will also go here. 用户空间工具： 我认为让用户通过虚拟机启动 9front 来进行创建或 fsck 操作不是长久之计。快照管理及相关的 ioctl 也将在此实现。

  • Posix persnicketies: The system that this was ported from was not a posix system, so there are likely to be many places where we don’t quite get the constraints right. POSIX 兼容性： 该系统移植自非 POSIX 系统，因此很可能在许多地方未能完全符合 POSIX 的约束。

  • Regress: There’s a small test suite for Plan 9. There’s none for OpenBSD. 回归测试： 目前有一个针对 Plan 9 的小型测试套件，但 OpenBSD 还没有。

  • Hardlinks / Kqueue: Easy to implement, but needs a refcount file by file. 硬链接 / Kqueue： 易于实现，但需要针对每个文件进行引用计数。

  • NFS: Has some ugly hooks, not sure what would be needed to add them. NFS： 包含一些丑陋的钩子（hooks），尚不确定添加它们需要做些什么。

  • Other missing pieces: Things like bootloader support, adding boot environments, quotas, and other niceties; this is well down the list. Quotas, in particular, would allow LLVM to continue in its attempt to grow to the size of the known universe without us preallocating a /usr/obj of that size. I’m sure I’ve forgotten some. 其他缺失部分： 例如引导加载程序支持、添加引导环境、配额（quotas）以及其他便利功能；这些目前优先级较低。特别是配额功能，可以让 LLVM 在尝试膨胀到“已知宇宙大小”时，无需我们预先分配那么大的 /usr/obj 空间。我肯定还遗漏了一些。

Right now

当前状态

I’m not looking to fix KNF; as things get touched, I’ll start to move them over, but I would prefer to keep the code closer with the original until it’s closer to ready for upstreaming. There are also a few non-fatal issues independent of 9front and OpenBSD, such as slow deletions of large files; I’ve got ideas to improve them. 我目前并不急于修复 KNF（内核代码风格）；随着代码的修改，我会逐步进行调整，但在代码接近合并到主线之前，我更倾向于保持代码与原始版本的一致性。此外还有一些与 9front 和 OpenBSD 无关的非致命问题，例如大文件删除缓慢；我已经有了改进它们的想法。

Getting it

如何获取

As one patch: https://orib.dev/gefs.diff 单个补丁文件：https://orib.dev/gefs.diff

The git repo is hidden on shithub, and the server is tiny and will get overloaded if people clone fresh repos from it. Instead, get a copy of the initial repo from github, and pull only the updates. Git 仓库托管在 shithub 上，由于服务器性能有限，如果大家直接克隆整个仓库会导致过载。建议先从 GitHub 获取初始仓库副本，然后仅拉取更新。

# first, get a copy of the upstream from somewhere else
# 首先，从其他地方获取上游副本
git clone https://github.com/openbsd/src
cd src

# now, add my server, and get just the diffs
# 现在，添加我的服务器，并仅获取差异部分
git remote add gefs git://shithub.us/ori/openbsd
git fetch gefs
git checkout -b gefs gefs/gefs

Note, I will be rebasing and force-pushing the branch occasionally in order to keep up with openbsd current; commit ids will change. 请注意，为了跟上 OpenBSD 的当前开发进度，我会不定期进行变基（rebase）和强制推送，提交 ID 将会发生变化。

← 返回新闻列表 / Back to news list