API不应更细粒度。它应该更易于使用。甚至以一致的方式更改简单的配置文件在POSIX中也是可怕的。对于事务，它看起来像：start_transaction（）open（）write（）close（）commit_transaction（）。对我而言，这比POSIX方法直观得多，在POSIX方法中，您需要注意创建一个新文件，事后重命名以及在正确的时间发出正确的fsync调用。现在尝试想象两个不同文件中的相关更改。使用POSIX，这需要您在应用程序级别上实现一些日记功能，因为无法自动重命名两个文件。 ＆gt;或者，也许，如果使用“快速交易”，我们可以确保该API对于开发人员来说是否可见，那么就该引入它并要求开发人员使用它测试应用程序了。这是错误的方法。仅当系统在正确的时间崩溃时，才能检测到误用。当然，还可以“快速交易”具有特定于实现的行为。这是当前API固有的。如果要测试应用程序是否符合此API的要求，则将需要某种模糊测试工具，将所有内容随机重新排序为POSIX允许的扩展范围，然后在某个随机时间点崩溃。 ＆gt;但是请不要介绍滥用开发人员无法轻易发现的API。 Fsync的故事本身就存在问题。不要让情况变得更糟。并行性中的排序问题始终很难发现。不仅适用于fs写入，而且适用于多个线程。如果要完全避免这种情况，则需要使用严格排序的实现（绝不能并行执行）。我怀疑许多人是否愿意为此付出代价。当前的API对于应用程序开发人员来说太可怕了。让我们创建一个更容易正确使用的API。是的，这意味着对于fs开发人员而言，它必须更难。