当您以 setuid 运行程序时，它将以该用户的所有权限运行。如果程序产生新的进程，它们将继承相同的权限。但文件系统 capabilities 不同。当您使用一组 capabilities 运行程序时，它产生的进程默认情况下不具有这些 capabilities；它们必须被显式地赋予。

Christoph Lameter 觉得这不直观，他发布了一个补丁来更改 capability inheritance 以匹配 setuid 继承的行为。这引发了一些争议。

一方面，文件系统 capabilities 从未在 POSIX 标准中完全定义，仅出现在后来被撤回的 POSIX 草案版本中，因此实际上无法讨论一种 capabilities 形式是否比另一种“更符合标准”。

还有其他问题，例如需要确保对 capabilities 的任何更改都不会破坏现有代码，以及需要确保任何最终解决方案保持安全。

Christoph 想法的一个问题是它将 capability inheritance 绑定到文件本身，但正如 Serge Hallyn 指出的那样，capabilities 既绑定到文件又绑定到执行文件的用户。最终，Christoph 决定调整他的代码以适应这个限制，引入一个新的 capability，它将列出用户可应用于给定文件的可继承 capabilities。

Yalin Wang 最近进行了一次未成功的尝试，希望 /proc/stat 列出给定系统上的所有 CPU，而不仅仅是在线的 CPU。这将是一个非常有用的功能，因为许多现代系统以很快的速度将 CPU 上线和下线。通常，实际使用的 CPU 数量不如可用的 CPU 数量重要。

他发布了一个补丁以相应地更改 /proc/stat，David Rientjes 指出 /sys/devices/cpu 文件将是更好的位置。Andrew Morton 也指出 /proc/cpuinfo 也是此类数据的好位置。所以，肯定有人支持 Yalin 的想法。

不幸的是，事实证明 Android 内核中的一些现有代码依赖于这些文件的当前行为——特别是需要在线 CPU 的数量，而不是系统上 CPU 的总数。由于现有用户依赖于现有行为，因此将更改纳入内核变得更加困难。Yalin 将不得不展示真正的需求，而不仅仅是合理的便利性，所以他的补丁毫无进展。

John Stultz 几年来一直在 GitHub 上维护一些 timekeeping 测试补丁，他最终希望将它们纳入内核，这样他就可以停止不断地向前移植它们。该测试会做各种事情，包括以某种旨在引发问题的方式更改系统时间。他询问他应该怎么做才能使这些补丁被内核人员接受。

来自 Richard Chochran 和 Shuah Khan 等人的一些评论总体上是支持的，但 Shuah 要求进行一些相当大的改动，这些改动会将 John 的代码与内核中的其他测试代码联系起来。John 说如果需要他很乐意这样做，但他其中一个目标是保持测试文件的隔离，这样它们中的任何一个都可以独立于系统上的任何其他东西运行。鉴于此，Shuah 收回了她的建议。

总的来说，这不是一组有争议的补丁，它们无疑很快就会进入内核。

保证文件系统一致性的备份的一个问题是，系统上的文件可能在备份过程中发生更改。有很多方法可以防止这种情况，但如果另一个进程已经为文件打开了文件描述符，备份软件就只能等待，否则就有可能复制不一致的文件版本。

Namjae Jeon 发布了一些补丁，通过实现 file freezing 来解决这个问题。这将允许备份软件临时阻止对给定文件的写入，即使该文件已经被另一个进程打开。

除了备份软件，其他工具如碎片整理软件也将受益于 Namjae 的补丁，通过防止对正在磁盘上重组的文件进行任何更改。

然而，正如 Jan Kara 指出的那样，Namjae 的代码存在一些潜在的竞争条件以及其他技术问题。Dave Chinner 将该代码描述为“非常容易出现竞争条件”。

目前尚不清楚这些补丁会发生什么。它们似乎提供了人们想要的功能，但竞争条件需要解决，代码需要足够干净和清晰，以便未来的修复和增强不太可能引入新问题。