IT虾米网

fsync性能问题详解

xmjava 2019年05月28日 程序员 130 0

最近在测试种发现程序里调用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是否启用。

发布评论

分享到:

IT虾米网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

linux下项目开发加载动态库:ldconfig与 /etc/ld.so.conf详解
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。