我试图弄清楚在并发断电并不是真正问题的情况下,同步或 fsync 操作真正需要运行的频率。我正在寻找 Linux 内核或 Posix 或 glibc API 在运行时可能提供的任何保证,而不是特定文件系统提供的功能。
如果函数 a() 打开一个文件,向其中写入数据,然后关闭该文件,所有这些都使用默认的阻塞 IO,那么该文件是否保证拥有该数据以供以后调用打开它而无需显式同步到磁盘?磁盘缓存或VFS层是否保证,如果稍后调用函数b()来打开该文件名进行读取,则与在打开之前调用fsync()的sync()时相同的数据将是可见的?或者是否应该始终为将由不同代码块读取的数据调用同步?
答案1
POSIX 保证read
a 之后发生的每个事件write
都保证看到新数据。从标准:
如果
read()
可以证明(通过任何方式)文件数据的 a 发生在write()
数据的 a 之后,则它必须反映这一点write()
,即使调用是由不同的进程进行的。类似的要求适用于对同一文件位置的多个写入操作。
fsync
不需要打电话。 Linux 和 Unix 上的许多程序都要求这样做以确保正确性和一致性,因此未能正确实现它将是一个严重的缺陷。