VFS（Virtual File System）的存在使得Linux可以兼容不同的文件系统，例如ext3、ext4、xfs、ntfs等等，其不仅具有为所有的文件系统实现一个通用的 外接口的作用，还具有另一个与系统性能相关的重要作用——缓存。VFS中引入了高速磁盘缓存的机制，这属于一种软件机制，允许内核将原本存在磁盘上的某些 信息保存在RAM中，以便对这些数据的进一步访问能快速进行，而不必慢速访问磁盘本身。高速磁盘缓存可大致分为以下三种：
目录项高速缓存——主要存放的是描述文件系统路径名的目录项对象
索引节点高速缓存——主要存放的是描述磁盘索引节点的索引节点对象
页高速缓存——主要存放的是完整的数据页对象，每个页所包含的数据一定属于某个文件，同时，所有的文件读写操作都依赖于页高速缓存。其是Linux内核所使用的主要磁盘高速缓存。
正是由于缓存的引入，所以VFS文件系统采用了文件数据延迟写的技术，因此，如果在调用系统接口写入数据时没有使用同步写模式，那么大多数据将会先保存在缓存中，待等到满足某些条件时才将数据刷入磁盘里。
内核是如何将数据刷入磁盘的呢？
何时把脏页写入磁盘
内核不断用包含块设备数据的页填充页高速缓存。只要进程修改了数据，相应的页就被标记为脏页，即把它的PG_dirty标志位置。
Unix系统允许把脏缓冲区写入块设备的操作延迟执行，因为这种策略可以显著地提高系统的性能。对高速缓存中的页的几次写操作可能只需对相应的磁盘块进行 一次缓慢的物理更新就可以满足。此外，写操作没有读操作那么紧迫，因为进程通常是不会因为延迟写而挂起，而大部分情况都因为延迟读而挂起。
一个脏页可能直到最后一刻（即直到系统关闭时）都一直逗留在主存中。然而，从延迟写策略的局限性来看，它有两个主要的缺点：
一、如果发生了硬件错误或者电源掉电的情况，那么就无法再获得RAM的内容，因此，从系统启动以来对文件进行的很多修改就丢失了。
二、页高速缓存的大小（由此存放它所需的RAM的大小）就可要很大——至少要与所访问块设备的大小不同。
因此，在下列条件下把脏页刷新（写入）到磁盘：
页高速缓存变得太满，但还需要更多的页，或者脏页的数量已经太多。
自从页变成脏页以来已过去太长时间。
进程请求对块设备或者特定文件任何待定的变化都进行刷新。通过调用sync()、fsync()或者fdatasync()系统调用来实现。
缓冲区页的 引入是问题更加复杂。与每个缓冲区页相关的缓冲区首部使内核能够了解每个独立块缓冲区的状态。如果至少有一个缓冲区首部的PG_Dirty标志被置位，就 应该设置相应缓冲区页的PG_dirty标志。当内核选择要刷新的缓冲区时，它扫描相应的缓冲区首部，并只把脏块的内容有效的写到磁盘。一旦内核把缓冲区 的所有脏页刷新到磁盘，就把页的PG_dirty标志清0。
谁来把脏页写入磁盘
由pdflush内核线程负责。早期版本的Linux使用bdfllush内核线程系统地扫描页高速缓存以搜索要刷新的脏页，并且使用另一个内核线程kupdate来保证所有的页不会“脏”太长时间。Linux 2.6用一组通用内核线程pdflush替代上述两个线程。当系统没有要刷新的脏页时，pdflush线程会自动处于睡眠状态，最后由pdflush_operation()函数来唤醒。
在下面几种情况下，系统会唤醒pdflush回写脏页：
1 、定时方式：
定时机制定时唤醒pdflush内核线程，周期为/proc/sys/vm/dirty_writeback_centisecs ，单位
是(1/100)秒，每次周期性唤醒的pdflush线程并不是回写所有的脏页，而是只回写变脏时间超过
/proc/sys/vm/dirty_expire_centisecs（单位也是1/100秒）。
注意：变脏的时间是以文件的inode节点变脏的时间为基准的，也就是说如果某个inode节点是10秒前变脏的，
pdflush就认为这个inode对应的所有脏页的变脏时间都是10秒前，即使可能部分页面真正变脏的时间不到10秒，
细节可以查看内核函数wb_kupdate()。
2、 内存不足的时候：
这时并不将所有的dirty页写到磁盘，而是每次写大概1024个页面，直到空闲页面满足需求为止。
3 、写操作时发现脏页超过一定比例：
当脏页占系统内存的比例超过/proc/sys/vm/dirty_background_ratio 的时候，write系统调用会唤醒
pdflush回写dirty page,直到脏页比例低于/proc/sys/vm/dirty_background_ratio，但write系统调
用不会被阻塞，立即返回。当脏页占系统内存的比例超过/proc/sys/vm/dirty_ratio的时候， write系
统调用会被被阻塞，主动回写dirty page，直到脏页比例低于/proc/sys/vm/dirty_ratio，这一点在
2.4内核中是没有的。
4 、用户调用sync系统调用：
这是系统会唤醒pdflush直到所有的脏页都已经写到磁盘为止。
linux系统在向存储设备上写数据的时候，其实，数据没有被立即写入到物理设备上，而一般处理过程是：
调用fwrite()将数据写入文件缓冲区（用户态进程的buffer)。
进程定期调用fflush()函数之后，把文件缓冲区中的文件数据写到文件系统中，此时数据还没有被真正写入到物理介质中。
fsync(fileno(fp))。该函数返回后，才能保证写入到了物理介质上。即先调用fileno获得文件描述符之后，再调用fsync函数返回后才将文件写入到物理介质上。
fflush和fsync的一些总结
1.提供者fflush是libc.a中提供的方法，fsync是linux系统内核提供的系统调用。
2.原形fflush接受一个参数FILE *.fflush(FILE *);fsync接受的时一个Int型的文件描述符。fsync(int fd);
3.功能fflush:是把C库中的缓冲调用write函数写到磁盘[其实是写到内核的缓冲区]。fsync：是把内核缓冲刷到磁盘上。
4.fsync 将文件相关的所有更改都发送到disk device。 这个调用是阻塞的，直到disk通知此函数传输完成。此函数也会将该文件的文件信息flush到disk。
5.fsync最终将缓冲的数据更新到文件里。
所以可以看出fflush和fsync的调用顺序应该是：
c库缓冲-----fflush---------〉内核页高速缓存--------fsync-----〉磁盘
与文件读写相关的几个重要概念
脏页：linux内核中的概念，因为硬盘的读写速度远赶不上内存的速度，系统就把读写比较频繁的数据事先放到内存中，以提高读写速度，这就叫高速缓存，linux是以页作为高速缓存的单位，当进程修改了高速缓存里的数据时，该页就被内核标记为脏页，内核将会在合适的时间把脏页的数据写到磁盘中去，以保持高速缓存中的数据和磁盘中的数据是一致的
内存映射：内存映射文件，是由一个文件到一块内存的映射。Win32提供了允许应用程序把文件映射到一个进程的函数 (CreateFileMapping)。内存映射文件与虚拟内存有些类似，通过内存映射文件可以保留一个地址空间的区域，同时将物理存储器提交给此区域，内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，而且在对该文件进行操作之前必须首先对文件进行映射。使用内存映射文件处理存储于磁盘上的文件时，将不必再对文件执行I/O操作，使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。
延迟写（delayed write）:传统的UNIX实现在内核中设有缓冲区高速缓存或页面高速缓存，大多数磁盘I/O都通过缓冲进行。当将数据写入文件时，内核通常先将该数据复制到其中一个缓冲区中，如果该缓冲区尚未写满，则并不将其排入输出队列，而是等待其写满或者当内核需要重用该缓冲区以便存放其他磁盘块数据时，再将该缓冲排入输出队列，然后待其到达队首时，才进行实际的I/O操作。这种输出方式被称为延迟写（delayed write）（Bach [1986]第3章详细讨论了缓冲区高速缓存）。
延迟写减少了磁盘读写次数，但是却降低了文件内容的更新速度，使得欲写到文件中的数据在一段时间内并没有写到磁盘上。当系统发生故障时，这种延迟可能造成 文件更新内容的丢失。为了保证磁盘上实际文件系统与缓冲区高速缓存中内容的一致性，UNIX系统提供了sync、fsync和fdatasync三个函数。
sync函数只是将所有修改过的块缓冲区排入写队列，然后就返回，它并不等待实际写磁盘操作结束。
通常称为update的系统守护进程会周期性地（一般每隔30秒）调用sync函数。这就保证了定期冲洗内核的块缓冲区。命令sync(1)也调用sync函数。
fsync函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fsync可用于数据库这样的应用程序，这种应用程序需要确保将修改过的块立即写到磁盘上。
fdatasync函数类似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的属性。
对于提供事务支持的数据库，在事务提交时，都要确保事务日志（包含该事务所有的修改操作以及一个提交记录）完全写到硬盘上，才认定事务提交成功并返回给应用层。
一个简单的问题：在*nix操作系统上，怎样保证对文件的更新内容成功持久化到硬盘？
1. write不够，需要fsync
一般情况下，对硬盘（或者其他持久存储 设备）文件的write操作，更新的只是内存中的页缓存（page cache），而脏页面不会立即更新到硬盘中，而是由操作系统统一调度，如由专门的flusher内核线程在满足一定条件时（如一定时间间隔、内存中的脏 页达到一定比例）内将脏页面同步到硬盘上（放入设备的IO请求队列）。
因为write调用不会等到硬盘IO完 成之后才返回，因此如果OS在write调用之后、硬盘同步之前崩溃，则数据可能丢失。虽然这样的时间窗口很小，但是对于需要保证事务的持久化 （durability）和一致性（consistency）的数据库程序来说，write()所提供的“松散的异步语义”是不够的，通常需要OS提供的同步IO（synchronized-IO）原语来保证：
1 #include 2 int fsync(int fd); fsync的功能是确保文件fd所有已修改的内容已经正确同步到硬盘上，该调用会阻塞等待直到设备报告IO完成。
PS：如果采用内存映射文件的方式进行文件IO（使用mmap，将文件的page cache直接映射到进程的地址空间，通过写内存的方式修改文件），也有类似的系统调用来确保修改的内容完全同步到硬盘之上：
1 #incude
2 int msync(void *addr, size_t length, int flags)msync需要指定同步的地址区间，如此细粒度的控制似乎比fsync更加高效（因为应用程序通常知道自己的脏页位置），但实际上（Linux）kernel中有着十分高效的数据结构，能够很快地找出文件的脏页，使得fsync只会同步文件的修改内容。
2. fsync的性能问题，与fdatasync
除了同步文件的修改内容（脏页），fsync还会同步文件的描述信息（metadata，包括size、访问时间st_atime & st_mtime等等），因为文件的数据和metadata通常存在硬盘的不同地方，因此fsync至少需要两次IO写操作，fsync的man page这样说：
"Unfortunately fsync() will always initialize two write operations : one for the newly written data and another one in order to update the modification time stored in the inode. If the modification time is not a part of the transaction concept fdatasync() can be used to avoid unnecessary inode disk write operations."
多余的一次IO操作，有多么昂贵呢？根据Wikipedia的数据，当前硬盘驱动的平均寻道时间（Average seek time）大约是3~15ms，7200RPM硬盘的平均旋转延迟（Average rotational latency）大约为4ms，因此一次IO操作的耗时大约为10ms左右。这个数字意味着什么？下文还会提到。
Posix同样定义了fdatasync，放宽了同步的语义以提高性能：
1 #include 2 int fdatasync(int fd); fdatasync的功能与fsync类似，但是仅仅在必要的情况下才会同步metadata，因此可以减少一次IO写操作。那么，什么是“必要的情况”呢？根据man page中的解释：
"fdatasync does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be corretly handled."
举例来说，文件的尺寸（st_size）如果变化，是需要立即同步的，否则OS一旦崩溃，即使文件的数据部分已同步，由于metadata没有同步，依然读不到修改的内容。而最后访问时间(atime)/修改时间(mtime)是不需要每次都同步的，只要应用程序对这两个时间戳没有苛刻的要求，基本无伤大雅。
PS：open时的参数O_SYNC/O_DSYNC有着和fsync/fdatasync类似的语义：使每次write都会阻塞等待硬盘IO完成。（实际上，Linux对O_SYNC/O_DSYNC做了相同处理，没有满足Posix的要求，而是都实现了fdatasync的语义）相对于fsync/fdatasync，这样的设置不够灵活，应该很少使用。
3. 使用fdatasync优化日志同步
文章开头时已提到，为了满足事务要求，数据库的日志文件是常常需要同步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的开销
参考：http://blog.csdn.net/cywosp/article/details/8767327
http://blog.chinaunix.net/uid-1911213-id-3412851.html
http://blog.csdn.net/lwj103862095/article/details/38268647
等