我正在尝试将whiteout 文件从AUFS 格式转换为内核覆盖FS 格式。这需要使用扩展属性 trust.overlay.opaque = y 标记某些目录。不幸的是，至少在默认情况下，FreeBSD 似乎只支持用户和系统命名空间的扩展属性。有什么办法可以绕过这个限制吗？这extattr 手册意味着我可以挂载的某些文件系统可能支持其他命名空间，可能包括受信任的命名空间，但我无法找到可以挂载的命名空间，并且确实允许使用受信任的命名空间。
不幸的是，我无法升级到受支持的 FreeBSD 版本。此外，虽然 KOFS 有一个标志可以从用户命名空间而不是受信任的命名空间读取其不透明的白色文件，但我们仍然在 tempfs 之上构建 KOFS，这不支持用户命名空间扩展属性。
有什么想法吗？
答案1
TL;DR：对于您的特定用例，您应该使用系统命名空间。
FreeBSD 的 extattr(9) 手册页在这里有些啰嗦，但它实际上意味着定义了两个标准属性命名空间：用户和系统，但文件系统 API 在技术上确实允许其他命名空间，因为它只是一个整数。 Linux 的 API 类似地是开放式的，但定义了四个标准命名空间，尽管其他命名空间在技术上是允许的，因为它们只是名称的字符串前缀。
在这两种情况下，真正重要的是您正在使用的文件系统实际支持哪些属性以及语义。正如您已经发现的，FreeBSD 的 tmpfs 仅支持系统属性。
Linux 的"user"命名空间直接映射到 FreeBSD 的用户命名空间（EXTATTR_NAMESPACE_USER或 1）。允许和不允许的内容可能存在一些细微的差异，对于那些期望它遵循基于文件模式位的 POSIX 语义的人来说，这可能会令人惊讶，但非特权用户通常可以期望在自己的文件上操作用户属性。
Linux 的"security","system"和"trusted"命名空间或多或少映射到 FreeBSD 的系统命名空间（EXTATTR_NAMESPACE_SYSTEM, 或 2）。这些需要提升权限才能访问：在 Linux 上，它取决于特定的命名空间和属性名称，但该CAP_SYS_ADMIN功能是一个很好的起点；在 FreeBSD 上这是PRIV_VFS_EXTATTR_SYSTEM特权。
Linux 拥有三个系统命名空间而不是一个系统命名空间的确切原因可能已经被时间遗忘了，但我怀疑内核开发人员希望为各种系统组件提供前缀以避免名称冲突，这被认为是最简洁的方法。 （非内核系统属性仍然会在"trusted"当时看来并不重要。）
为了完整起见，MacOS 还具有扩展属性。它的 API 与 Linux 很接近，只是在命名空间方面有点混乱。属性往往有一个前缀，例如"com.apple."，但这只是避免名称冲突的约定，内核很少关注它。一般来说，这些都在用户命名空间中，除非您提供额外的选项，例如XATTR_SHOWCOMPRESSION在这种情况下会出现一些其他名称，其中一些甚至无法由 root 访问。同时，关于 Solaris 的讨论越少越好。