函数sync fsync 和 fdatasync 的区别

缓冲

传统的UNIX实现的内核中都设置有缓冲区或者页面高速缓存，大多数磁盘IO都是通过缓冲写的。
当你想将数据write进文件时，内核通常会将该数据复制到其中一个缓冲区中，如果该缓冲没被写满的话，内核就不会把它放入到输出队列中。
当这个缓冲区被写满或者内核想重用这个缓冲区时，才会将其排到输出队列中。等它到达等待队列首部时才会进行实际的IO操作。

这里的输出方式就是大家耳熟能详的：延迟写
这个缓冲区就是大家耳熟能详的：OS Cache

脏页

linux内核中的概念，由于硬盘的读写速度远赶不上内存的速度，系统就把读写比较频繁的数据事先放到内存中，以提升读写速度，这就叫高速缓存，linux是以页做为高速缓存的单位，当进程修改了高速缓存里的数据时，该页就被内核标记为脏页，内核将会在合适的时间把脏页的数据写到磁盘中去，以保持高速缓存中的数据和磁盘中的数据是一致的。

内存映射

内存映射文件，是由一个文件到一块内存的映射。Win32提供了容许应用程序把文件映射到一个进程的函数 (CreateFileMapping)。内存映射文件与虚拟内存有些相似，经过内存映射文件能够保留一个地址空间的区域，同时将物理存储器提交给此区域，内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，并且在对该文件进行操做以前必须首先对文件进行映射。使用内存映射文件处理存储于磁盘上的文件时，将没必要再对文件执行I/O操做，使得内存映射文件在处理大数据量的文件时能起到至关重要的做用。

延迟写

传统的UNIX实如今内核中设有缓冲区高速缓存或页面高速缓存，大多数磁盘I/O都经过缓冲进行。当将数据写入文件时，内核一般先将该数据复制到其中一个缓冲区中，若是该缓冲区还没有写满，则并不将其排入输出队列，而是等待其写满或者当内核须要重用该缓冲区以便存放其余磁盘块数据时，再将该缓冲排入到输出队列，而后待其到达队首时，才进行实际的I/O操做。这种输出方式就被称为延迟写。

延迟写的优缺点

很明显、延迟写降低了磁盘读写的次数，但同时也降低了文件的更新速度。
这样当OS Crash时由于这种延迟写的机制可能会造成文件更新内容的丢失。而为了保证磁盘上的实际文件和缓冲区中的内容保持一致，UNIX系统提供了三个系统调用：sync、fsync、fdatasync。

sync函数

sync函数只是将所有修改过的块缓冲区排入写队列，然后就返回，它并不等待实际写磁盘操作结束。通常称为update的系统守护进程会周期性地（一般每隔30秒）调用sync函数。这就保证了定期冲洗内核的块缓冲区。命令sync(1)也调用sync函数。

fsync函数

fsync函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fsync可用于数据库这样的应用程序，这种应用程序需要确保将修改过的块立即写到磁盘上。

fdatasync函数

fdatasync函数相似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的属性。

write不够，需要fsync

一般情况下，对硬盘（或者其他持久存储设备）文件的write操作，更新的只是内存中的页缓存（page cache），而脏页面不会立即更新到硬盘中，而是由操作系统统一调度，如由专门的flusher内核线程在满足一定条件时（如一定时间间隔、内存中的脏页达到一定比例）内将脏页面同步到硬盘上（放入设备的IO请求队列）。

因为write调用不会等到硬盘IO完成之后才返回，因此如果OS在write调用之后、硬盘同步之前崩溃，则数据可能丢失。虽然这样的时间窗口很小，但是对于需要保证事务的持久化（durability）和一致性（consistency）的数据库程序来说，write()所提供的“松散的异步语义”是不够的，通常需要OS提供的同步IO（synchronized-IO）原语来保证：

#include <fcntl.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
const char* journal_filename = “journal.log”;
void write_journal_entry (char* entry)
{
   int fd = open (journal_filename, O_WRONLY | O_CREAT | O_APPEND, 0660);
   write (fd, entry, strlen (entry));
   write (fd, “\n”, 1);
   fsync (fd); //确保 fd 所指向文件的更新被写入磁盘
   close (fd);
}

fsync的功能是确保文件fd所有已修改的内容已经正确同步到硬盘上，该调用会阻塞等待直到设备报告IO完成。

如果采用内存映射文件的方式进行文件IO（使用mmap，将文件的page cache直接映射到进程的地址空间，通过写内存的方式修改文件），也有类似的系统调用来确保修改的内容完全同步到硬盘之上：

#incude <sys/mman.h>
int msync(void *addr, size_t length, int flags)

msync需要指定同步的地址区间，如此细粒度的控制似乎比fsync更加高效（因为应用程序通常知道自己的脏页位置），但实际上（Linux）kernel中有着十分高效的数据结构，能够很快地找出文件的脏页，使得fsync只会同步文件的修改内容。

fsync的性能问题，与fdatasync

除了同步文件的修改内容（脏页），fsync还会同步文件的描述信息（metadata，包括size、访问时间st_atime & st_mtime等等），因为文件的数据和metadata通常存在硬盘的不同地方，因此fsync至少需要两次IO写操作。
多余的一次IO操作，有多么昂贵呢？当前硬盘驱动的平均寻道时间（Average seek time）大约是3~15ms，7200RPM硬盘的平均旋转延迟（Average rotational latency）大约为4ms，因此一次IO操作的耗时大约为10ms左右。
fdatasync的功能与fsync类似，但是仅仅在必要的情况下才会同步metadata，因此可以减少一次IO写操作。
那么，什么是“必要的情况”呢？
举例来说，文件的尺寸（st_size）如果变化，是需要立即同步的，否则OS一旦崩溃，即使文件的数据部分已同步，由于metadata没有同步，依然读不到修改的内容。而最后访问时间(atime)/修改时间(mtime)是不需要每次都同步的，只要应用程序对这两个时间戳没有苛刻的要求，基本无伤大雅。

使用fdatasync优化日志同步

为了满足事务要求，数据库的日志文件是常常需要同步IO的。由于需要同步等待硬盘IO完成，所以事务的提交操作常常十分耗时，成为性能的瓶颈。
在Berkeley DB下，如果开启了AUTO_COMMIT（所有独立的写操作自动具有事务语义）并使用默认的同步级别（日志完全同步到硬盘才返回），写一条记录的耗时大约为5~10ms级别，基本和一次IO操作（10ms）的耗时相同。
我们已经知道，在同步上fsync是低效的。但是如果需要使用fdatasync减少对metadata的更新，则需要确保文件的尺寸在write前后没有发生变化。日志文件天生是追加型（append-only）的，总是在不断增大，似乎很难利用好fdatasync。
且看Berkeley DB是怎样处理日志文件的：（巧妙的使用了fdatasync）

每个log文件固定为10MB大小，从1开始编号，名称格式为“log.%010d"
每次log文件创建时，先写文件的最后1个page，将log文件扩展为10MB大小
向log文件中追加记录时，由于文件的尺寸不发生变化，使用fdatasync可以大大优化写log的效率
如果一个log文件写满了，则新建一个log文件，也只有一次同步metadata的开销

缓冲

脏页