资料聚集(innodb_flush_method 与 File I/O)

innodb_flush_method 与 File I/O

陶方在《innodb_flush_method带来的性能影响》中从实验角度比较了fdatasync，O_DSYNC和O_DIRECT在性能上的差别。本文将试图从Linux/Unix"文件I/O"（unbuffered I/O）的角度来解释innodb_flush_method是如何影响MySQL的I/O。【附录1】

innodb_flush_log_at_trx_commit参数肯定日志文件什么时候write、flush。innodb_flush_method则肯定日志及数据文件如何write、flush。在Linux下，innodb_flush_method能够取以下值：fdatasync, O_DSYNC, O_DIRECT，那这三个值分别是如何影响文件写入的？首先咱们须要先来了解Linux的文件I/O是如何工做的。

先来看看Linux/Unix文件I/O的一个典型例子：（Linux 2.6.24测试，gcc编译）

/**
	A test about syscall of File I/O
	Author:supu@TaobaoDBA
	supu@taobao.com http://orczhou.com http://www.taobaodba.com
*/
#include   "stdlib.h"           /* for exit */
#include   "unistd.h"           /* for write fdatasync*/
#include    "fcntl.h"           /* for open  */

int main(void){
	int fd;

	if((fd=open("/home/zzx/test.file",O_WRONLY|O_APPEND|O_DSYNC))<0){
		exit(1);
        }

        char buff[]="abcdef";
        if(write(fd,buff,6)!= 6){
                exit(2);
        }
        if(fdatasync(fd)==-1){
                exit(3);
        }

        exit(0);
}

程序描述了通常的文件I/O操做的三个过程open、write、fdatasync，分别是打开文件、写文件、flush操做（将文件缓存刷到磁盘上）。

1、Open阶段

open("test.file",O_WRONLY|O_APPDENT|O_SYNC))

系统调用Open会为该进程一个文件描述符fd【附录2】。这里使用了O_WRONLY|O_APPDENT|O_SYNC打开文件: O_WRONLY表示咱们以"写"的方式打开，告诉内核咱们须要向文件中写入数据； O_APPDENT告诉内核以"追加"的方式写文件； O_DSYNC告诉内核，当向文件写入数据的时候，只有当数据写到了磁盘时，写入操做才算完成（write才返回成功）。 和O_DSYNC同类的文件标志，还有O_SYNC,O_RSYNC，O_DIRECT。 O_SYNC比O_DSYNC更严格，不只要求数据已经写到了磁盘，并且对应的数据文件的属性（例如文件长度等）也须要更新完成才算write操做成功。可见O_SYNC较之O_DSYNC要多作一些操做。 O_RSYNC表示文件读取时，该文件的OS cache必须已经所有flush到磁盘了【附录3】； 若是使用O_DIRECT打开文件，则读/写操做都会跳过OS cache，直接在device（disk）上读/写。由于没有了OS cache，因此会O_DIRECT下降文件的顺序读写的效率。 2、Write阶段

write(fd,buf,6)

在使用open打开文件得到文件描述符以后，咱们就能够调用write函数来写入数据了，write会根据前面的open参数不一样，而表现不一样。

3、Flush阶段

fdatasync(fd) == -1

write操做后，咱们还调用了fdatasync来确保文件数据flush到了disk上。fdatasync返回成功后，那么能够认为数据已经写到了磁盘上。像这样的flush的函数还有fsync、sync。

Fsync和fdatasync的区别等同于O_SYNC和O_DSYNC的区别。 Sync函数表示将文件在OS cache中的数据排入写队列，并不确认是否真的写磁盘了，因此sync并不能够靠。 忽略文件打开的过程，一般咱们会说“写文件”有两个阶段，一个是调用write咱们称为写数据阶段（实际上是受open的参数影响），调用fsync（或者fdatasync）咱们称为flush阶段。

回到MySQL，参数Innodb_flush_method(Linux)能够设定为：Fdatasync、O_DSYNC、O_DIRECT。咱们看看这个三个参数是如何影响程序MySQL对日志和数据文件的操做：

Open log	Flush log	Open datafile	Flush data
Fdatasync		fsync()		fsync()
O_DSYNC	O_SYNC			fsync()
O_DIRECT		fsync()	O_DIRECT	Fsync()

fdatasync被认为是安全的，由于在MySQL总会调用fsync来flush数据。使用O_DSYNC是有些风险的，有些OS会忽略该参数O_SYNC。

咱们看到O_DIRECT和fdatasync和很相似，可是它会使用O_DIRECT来打开数据文件。有数据代表，若是是大量随机写入操做，O_DIRECT会提高效率。可是顺序写入和读取效率都会下降。因此使用O_DIRECT须要谨慎。

参考文章：

Unix环境高级编程（第二版） http://rdc.taobao.com/blog/dba/html/296_innodb_flush_method_performance.html http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html http://xiaomeng.yo2.cn/articles/buffered-io-and-non-buffered-io.html http://articles.directorym.net/Operating_Systems_System_Calls_and_IO-a894576.html http://www.ibm.com/developerworks/cn/linux/l-cn-read/

http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html

系统调用：http://www.ibm.com/developerworks/cn/linux/kernel/syscall/part1/index.html

【附录1】文章须要你了解什么是“系统调用“，参考：

http://www.ibm.com/developerworks/cn/linux/kernel/syscall/part1/index.html

能够简单的理解为：“系统调用“是在内核之上的一层封装。由内核直接提供接口，“系统调用”须要陷入内核执行（内核态）。其中fdatasync就是一个系统调用，该系统调用能够通知OS马上将OS Cache中的数据Flush到磁盘文件中。

【附录2】这时候内核会为该该进程打开的文件分配一个文件描述符，并将该文件描述符返回给该进程。在内核的文件表中新建一个文件项，标记文件状态、文件当前偏移、以及I节点（v节点）的位置，内核还会打开该文件的I节点（这里记录文件的操做的函数指针，例如读操做、写操做）。

【附录3】O_RSYNC个人理解是，对于同一个文件描述符能够保证读数据安全。同一个文件描述符包括dup和fcntl函数dup的文件描述符，即共用同一个文件表项。O_RSYNC不是咱们今天关注的，暂时忽略

未解问题:

O_DIRECT在哪些OS(或者FS)上可以正常工做？

O_SYNC在哪写OS上不能正常工做呢？

内核的read、write是FS级别的仍是内核(kernel)级别？

文章innodb_flush_method带来的性能影响中O_DSYNC、和fdatasync效率差不少，这是为何？