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是否启用。
