脏页:linux内核中的概念，因为硬盘的读写速度远赶不上内存的速度，系统就把读写比较频繁的数据事先放到内存中，以提高读写速度，这就叫高速缓存，linux是以页作为高速缓存的单位，当进程修改了高速缓存里的数据时，该页就被内核标记为脏页，内核将会在合适的时间把脏页的数据写到磁盘中去，以保持高速缓存中的数据和磁盘中的数据是一致的。
内存映射：内存映射文件，是由一个文件到一块内存的映射。Win32提供了允许应用程序把文件映射到一个进程的函数 (CreateFileMapping)。内存映射文件与虚拟内存有些类似，通过内存映射文件可以保留一个地址空间的区域，同时将物理存储器提交给此区域，内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，而且在对该文件进行操作之前必须首先对文件进行映射。使用内存映射文件处理存储于磁盘上的文件时，将不必再对文件执行I/O操作，使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。
//摘录自百度百科
延迟写（delayed write）: 传统的UNIX实现在内核中设有缓冲区高速缓存或页面高速缓存，大多数磁盘I/O都通过缓冲进行。 当将数据写入文件时，内核通常先将该数据复制到其中一个缓冲区中，如果该缓冲区尚未写满，则 并不将其排入输出队列，而是等待其写满或者当内核需要重用该缓冲区以便存放其他磁盘块数据时， 再将该缓冲排入到输出队列，然后待其到达队首时，才进行实际的I/O操作。这种输出方式就被称为延迟写。
//摘录自《UNIX环境高级编程第三版》P65
延迟写减少了磁盘读写次数，但是却降低了文件内容的更新速度，使得欲写到文件中的数据在一段时间内并没有写到磁盘上。当系统发生故障时，这种延迟可能造成文件更新内容的丢失。为了保证磁盘上实际文件系统与缓冲区高速缓存中内容的一致性，UNIX系统提供了sync、fsync和fdatasync三个函数。
sync函数只是将所有修改过的块缓冲区排入写队列，然后就返回，它并不等待实际写磁盘操作结束。
通常称为update的系统守护进程会周期性地（一般每隔30秒）调用sync函数。这就保证了定期冲洗内核的块缓冲区。命令sync(1)也调用sync函数。
fsync函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。
fsync可用于数据库这样的应用程序，这种应用程序需要确保将修改过的块立即写到磁盘上。
fdatasync函数类似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的属性。
对于提供事务支持的数据库，在事务提交时，都要确保事务日志（包含该事务所有的修改操作以及一个提交记录）完全写到硬盘上，才认定事务提交成功并返回给应用层。
：标准IO函数（如fread，fwrite等）会在内存中建立缓冲，该函数刷新内存缓冲，将内容写入内核缓冲，要想将其真正写入磁盘，还需要调用fsync。（即先调用fflush然后再调用fsync，否则不会起作用）。fflush以指定的文件流描述符为参数（对应以fopen等函数打开的文件流），仅仅是把上层缓冲区中的数据刷新到内核缓冲区就返回，
因此相对于fsync而言不是很安全，还需要再调用一下fsync来把数据真正写入硬盘。使用函数
int fileno(FILE *stream);
把文件流描述符（fp）转换为文件描述符（fd），以方便fsync的调用，那么，在linux操作系统上，怎样才能保证数据被正确地写入外部永久存储介质？
对于write函数，我们认为该函数一旦返回，数据便已经写到了文件中。但是这种概念只是宏观上的，一般情况下，对硬盘（或者其他持久存储设备）文件的write操作，更新的只是内存中的页缓存（page cache），而脏页不会立即更新到硬盘中，而是由操作系统统一调度，如flusher内核线程在满足一定条件时（一定时间间隔、内存中
的脏页达到一定比例）将脏页面同步到硬盘上（放入设备的IO请求队列）。因为write调用不会等到硬盘IO完成之后才返回，设想如果操作系统在write调用之后、硬盘同步之前崩溃，则数据可能丢失。虽然这样的时间窗口很小，但是对于需要保证事务的持久化（durability）和一致性（consistency）的数据库程序来说，write()所提供的“松散的异步语义”是不够的，通常需要操作系统提供的同步IO（synchronized-IO）原语来保证：
函数原型：
int fsync(int fd);
fsync的功能是确保文件fd所有已修改的内容已经正确同步到硬盘上，该调用会阻塞等待直到设备报告IO完成。
#incude <sys/mman.h>
int msync(void *addr, size_t length, int flags)
除了同步文件的修改内容（脏页），fsync还会同步文件的描述信息（metadata，包括size、访问时间等等），因为文件的数据和metadata通常存在硬盘的不同地方，因此fsync至少需要两次IO写操作，多余的一次IO操作，根据Wikipedia的数据，当前硬盘驱动的平均寻道时间（Average seek time）大约是3~15ms，7200RPM硬盘的平均旋转延迟（Average rotational latency）大约为4ms，因此一次IO操作的耗时大约为10ms左右。Posix同样定义了fdatasync，放宽了同步的语义以提高性能：
int fdatasync(int fd);
fdatasync的功能与fsync类似，但是仅仅在必要的情况下才会同步，因此可以减少一次IO写操作。
“fdatasync does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be corretly handled.”
//摘录自man手册
举例来说，文件的尺寸（st_size）如果变化，是需要立即同步的，否则OS一旦崩溃，即使文件的数据部分已同步，由于metadata没有同步，依然读不到修改的内容。而最后访问时间(atime)/修改时间(mtime)是不需要每次都同步的，只要应用程序对这两个时间戳没有苛刻的要求，基本没有问题。
补充：函数open的参数O_SYNC/O_DSYNC有着和fsync/fdatasync类似的含义：使每次write都会阻塞等待硬盘IO完成。
O_SYNC 使每次write等待物理I/O操作完成，包括由write操作引起的文件属性更新所需的I/O。
O_DSYNC 使每次write等待物理I/O操作完成，但是如果该写操作并不影响读取刚写入的数据，则不需等待文件属性被更新。
注意区别：
O_DSYNC和O_SYNC标志有微妙的区别：仅当文件属性需要更新以反映文件数据变化（例如，更新文件大小以反映文件中包含了更多数据）时，O_DSYNC标志才影响文件属性。而设置O_SYNC标志后，数据和属性总是同步更新。当文件用O_DSYN标志打开，在重写其现有的部分内容时，文件时间属性不会同步更新。于此相反，文件如果是用O_SYNC标志打开的，那么对于该文件的每一次write都将在write返回前更新文件时间，这与是否改写现有字节或追加文件无关。相对于fsync/fdatasync，这样的设置不够灵活，应该很少使用。
3. 使用fdatasync优化日志同步（来自http:///cywosp/article/details/8767327）
为了满足事务要求，数据库的日志文件是常常需要同步IO的。由于需要同步等待硬盘IO完成，所以事务的提交操作常常十分耗时，成为性能的瓶颈。在Berkeley DB下，如果开启了AUTO_COMMIT（所有独立的写操作自动具有事务语义）并使用默认的同步级别（日志完全同步到硬盘才返回），写一条记录的耗时大约为5~10ms级别，基本和一次IO操作（10ms）的耗时相同。
我们已经知道，在同步上fsync是低效的。但是如果需要使用fdatasync减少对metadata的更新，则需要确保文件的尺寸在write前后没有发生变化。日志文件天生是追加型（append-only）的，总是在不断增大，似乎很难利用好fdatasync。
Berkeley DB是处理日志文件的步骤：
1.每个log文件固定为10MB大小，从1开始编号，名称格式为“log.%010d"
2.每次log文件创建时，先写文件的最后1个page，将log文件扩展为10MB大小
3.向log文件中追加记录时，由于文件的尺寸不发生变化，使用fdatasync可以大大优化写log的效率
4.如果一个log文件写满了，则新建一个log文件，也只有一次同步metadata的开销
三、总结
1、如果是对所有的缓冲区发出写硬盘的命令，应该使用sync函数，但应该注意该函数仅仅只是把该命令放入队列就返回了，在编程时需要注意。
2、如果是要把一个已经打开的文件所做的修改提交到硬盘，应调用fsync函数，该函数会在数据实际写入硬盘后才返回，因此是最安全最可靠的方式。
3、如果是针对一个已经打开的文件流操作，则应该首先调用fsync函数把修改同步到内核缓冲区，然后再调用fsync把修改真正的同步到硬盘。
四、附man手册关于fsync，fdatasync部分
fsync() transfers (“flushes”) all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file
descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the sys‐
tem crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device
reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also needed.
fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent
data retrieval to be correctly handled. For example, changes to st_atime or st_mtime (respectively, time of last access and time of last
modification; see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly. On
the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush.
The aim of fdatasync() is to reduce disk activity for applications that do not require all metadata to be synchronized with the disk.
————————————————