iphone - iOS/iPhone日记/文件系统缓存

Question

从本地设备测试中，我已经看到将文件写入iOS文件系统(无论您使用何种级别的 call )通常会在文件完全提交到闪存之前返回成功。这意味着，如果您硬重置设备然后重新启动，则文件可能会回滚(如果写入已完成或是原子的)或已损坏。造成这种延迟的原因是什么(感谢文档，我无法找到任何东西)，并且有一种方法可以在实际文件系统写入完成时获得反馈。例如，我想确认来自远程服务器的部分数据的接收和存储，但是我发现在成功写入“报告”之后对数据进行确认可能会导致硬崩溃或电源故障而导致数据丢失。

Answer 1

由于这是一个有4年历史的问题，因此，我不仅会提供答案，而且会提供我在搜索时所走的路。

我在官方文档File System Programming Guide中找不到任何明确的解释。 Performance Tips section中只有一个线索。它指出:

应用程序可以使用F_NOCACHE标志调用BSD fcntl函数，以启用或禁用文件缓存。有关此功能的更多信息，请参见fcntl。

启用F_NOCACHE标志并不能解决您要说明的问题，但是，fcntl方法的手册指出，您可能会发现一个有趣的选项:

F_FULLFSYNC执行与fsync(2)相同的操作，然后要求驱动器将所有缓冲的数据刷新到永久存储设备

(来自man fcntl，请参见here)。

我已经检查了fsync手册以了解更多详细信息。最终，它给了我关于问题和解决方案的最清晰，最易理解的解释:

请注意，尽管fsync()会将所有数据从主机刷新到驱动器(即“永久存储设备”)，但驱动器本身可能在相当长的一段时间内未将数据物理写入磁盘，并且可能会被写入磁盘。有序序列。

具体来说，如果驱动器掉电或操作系统崩溃，则应用程序可能会发现仅写入了部分数据或未写入任何数据。磁盘驱动器还可以对数据进行重新排序，以便可以提供以后的写操作，而没有前面的写操作。

这不是理论上的优势情况。这种情况很容易在实际工作负载和驱动器电源故障中重现。

对于需要严格保证数据完整性的应用程序，Mac OS X提供了F_FULLFSYNC fcntl。 F_FULLFSYNC fcntl要求驱动器将所有缓冲的数据刷新到永久存储中。需要严格执行写入顺序的应用程序(例如数据库)应使用F_FULLFSYNC来确保按期望的顺序写入其数据。

(来自man fsync，请参见here)。

是的，这绝对不是理论上的优势案例。值得庆幸的是，一旦您知道了问题所在，解决方案就很简单了:

let filePath: String = "your file path"

// you can use other option than read-write
let fd = open(String(path.utf8), O_RDWR)

// if fd is -1, there was an error opening file, handle it as you wish
guard fd != -1 else { return }

// syncResult is -1 if sync operation failed, handle it as you wish
let syncResult = fcntl(fd, F_FULLFSYNC)

// don't forget to close opened file
close(fd)

fcntl完成后，您的数据将被保存。

请注意，此操作比通常写入文件(通过 NSFileManager或 writeToURL方法系列)要慢。如果出现性能问题，最好将写操作转移到后台线程。