这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章，但是由于刘峥同学目前没有blog，征得本人同意，贴在我的blog上，如果大家喜欢，请去新浪微博关注他。:)

   日前线上在升级到Ext4文件系统后出现应用写操作延迟开销增大的问题。造成这一问题的根源目前已经查明，是由于Ext4文件系统的一个新特性——Delay Allocation造成的。(后面简称delalloc)

   在详细分析这一问题之前，先来介绍一下Ext4文件系统的delalloc特性。这一特性简要概括起来就是将以前在buffer IO中每次写操作都会涉及的磁盘块分配过程推迟到数据回写时再进行。我们知道，在进行Buffer Write时，系统的实际操作仅仅是为这些数据在操作系统内分配内存页(page cache)并保存这些数据，等待用户调用fsync等操作强制刷新或者等待系统触发定时回写过程。在数据拷贝到page cache这一过程中，系统会为这些数据在磁盘上分配对应的磁盘块。

   而在使用delalloc后，上面的流程会略有不同，在每次Buffer Write时，数据会被保存到page cache中，但是系统并不会为这些数据分配相应的磁盘块，仅仅会查询是否有已经为这些数据分配过磁盘块，以便决定后面是否需要为这些数据分配磁盘块。在用户调用fsync或者系统触发回写过程时，系统会尝试为标记需要分配磁盘块的这些数据分配磁盘块。这样，文件系统可以为这些属于同一个文件的数据分配尽量连续的磁盘空间，从而优化后续文件的访问性能(因为传统机械硬盘顺序读写的性能要比随机读写好很多)。

   了解完delalloc特性的工作过程后，我们开始分析线上遇到的问题。线上应用的I/O模式可以简化为一个单线程追加写操作的程序，每秒写入2、3M数据，写操作后等待系统自动将数据回写到磁盘。在使用delalloc后，每次Buffer Write操作，系统都会去查询数据是否分配了磁盘块，这一过程需要获得一把读锁 (i_data_sem)。由于这时还没有触发回写操作，因此可以顺利获取i_data_sem，系统完成数据拷贝工作，并返回。由于仅仅是内存拷贝的过程，所以这一操作速度相当快。当系统开始进行回写操作时，系统会成批为数据分配磁盘块，这一过程同样需要获取i_data_sem，并且需要加写锁以保证数据的一致性。由于使用delalloc后，需要分配的磁盘块比nodelalloc情况下多很多(nodelalloc情况下每5秒文件系统会提交日志触发回写；delalloc情况下，系统会在约每30秒左右触发一次回写)，因此这一延迟时间较长。如果这时应用程序进行一次Buffer Write，则该操作在尝试获得i_data_sem时会等待上述磁盘块分配完成。由此造成写操作等待很长时间，从而影响应用程序的响应延迟。

   在上面的分析中已经提到，delalloc是将多次磁盘块分配的过程合并到一次中来进行，那么是否真如预想的那样，delalloc的平均延迟会小于nodelalloc的情况呢？我们使用fio来做如下测试：设置bs=4k，单线程每秒追加写入5M，程序运行3分钟，我们来看一下最后fio对延迟的统计结果：

   delalloc:

   lat (usec): min=2 , max=193466 , avg= 5.86, stdev=227.91

   nodelalloc:

   lat (usec): min=3 , max=16388 , avg= 7.00, stdev=28.92

   从上面的统计结果看，写操作的平均延迟：打开delalloc后为5.86us，关闭delalloc后为7.00us；最小延迟delalloc为2us，nodelalloc为3us；但是最大延迟delalloc为193.466ms，nodelalloc下仅为16.388ms。可见delalloc确实将多个写操作请求集中到了一起来进行。因此在提供较低平均延迟的情况下，会造成某次写操作的延迟较大。

   通过上面的分析可以看到，目前会受到Ext4的delalloc特性影响的应用必须具备如下条件：

   0. Buffer IO

   1. 写操作过程中会涉及磁盘块的分配，主要是记录日志这类追加写操作；

   2. 每次写操作后没有刷新数据，而是等待系统自动进行回写；

   3. 对延迟有较高要求。

   解决方法：关闭delalloc

   1. mount -t ext4 -o remount,nodelalloc /${dev} /${mnt};

   2. 编辑/etc/fstab中相关mount项，添加nodelalloc挂载参数.

建议继续学习：

1. 哇，让你的DB再快一倍：ext4 vs xfs对比测试    (阅读：4086)