fsync性能问题

最近在测试种发现程序里调用fsync刷文件到磁盘时,开销只有几百微秒,于是对fsync相关机制进行了一番调查。

磁盘(或RAID卡)自身通常会有硬件缓存机制,对于写操作,有write back和write through两种机制,前者将数据写至缓存就会返回,而后者则会将数据写到磁盘介质上。当使用write back机制时,fsync刷的文件数据可能只是写到磁盘缓存就返回了,导致从应用看来,写数据到磁盘的开销很小(实际上并未执行磁盘写操作);所以,使用write back机制时,即使上层应用显式fsync成功,数据也是可能丢失的,比如缓存里的数据还未刷到磁盘时掉电了,有些存储设备会使用备用电池(BBU,Battery backup unit)来避免掉电时缓存数据丢失。

如果要保证fsync调用成功后,数据一定持久化到磁盘,则要使用内核的write barrier机制。该机制通过在IO操作之前和之后显式刷新存储设备的缓存来达到目的,在文件系统mount的时候可以指定是否开启barrier机制,ext4默认启用barrier机制。

对于内存映射(mmap)的文件数据,msync的功能与fsync类似,将内存映射数据刷到磁盘,msync使用时有3个标志。

  • MS_SYNC,数据同步刷到磁盘后返回(可能只是写到磁盘缓存)
  • MS_ASYNC, 对于更新的文件数据会提交IO操作到底层,但不会等IO操作执行完成,而是立即返回
  • MS_INVALIDATE,更新文件对应的其它映射数据(如内存区域M1、M2都映射了文件F的数据,如果在msync M1的时候指定了该标记,则M2内存区域里的数据也会被更新)。

要想映射内存msync后被持久化到磁盘,需要使用MS_SYNC标记;而msync调用后数据是否一定持久化,则要看存储设备使用的缓存机制以及内核write barrier是否启用。










本文转自 jiu~ 博客园博客,原文链接:http://www.cnblogs.com/jiu0821/p/7682015.html,如需转载请自行联系原作者
上一篇:ASP.NET Core : 十三.httpClient.GetAsync 报SSL错误的问题


下一篇:frida hook