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

    前几天微博上有同学问我磁盘util达到了100%时程序性能下降的问题，由于信息实在有限，我也没有办法帮太大的忙，这篇blog只是想给他列一下在磁盘util很高的时候如何通过blktrace+debugfs找到发生IO的文件，然后再结合自己的应用程序，分析出这些IO到底是谁产生的，最终目的当然是尽量减少不必要的IO干扰，提高程序的性能。 blktrace是Jens Axobe写的一个跟踪IO请求的工具，Linux系统发起的IO请求都可以通过blktrace捕获并分析。

    最近由于一些控制IO带宽的需求，开始研究CFQ以及对应的IO cgroup，今天baidu了一下，竟然发现没有多少中文的介绍，所以准备写一个系列，介绍一下这个调度器，粗粗想了一下，大概可以灌四篇水，包括CFQ的基本介绍，CFQ各个配置参数的含义和调优，CFQ的基本架构以及CFQ+cgroup。各位看官要是觉得还有什么值得写的，请留言给我或者直接新浪微博 @淘伯瑜。闲话少说，言归正传。 CFQ是Completely Fair Queuing的缩写，顾名思义，他存在的主要目的就是为了保证公平性， 并为此做了大量的工作。为了说明他的公平性，让我们先来简单看看另外目前kernel另外两个IO调度器，noop和deadline。那么怎么看自己目前硬盘的调度器呢？

    现在的linux内核中对于缓存的管理都是以page的形式进行的，也就是说在系统底层只存在各种page，这些page保存在不同的tree 中，buffer这个概念实际上已经过时了，但是为了保持对过往系统的兼容性，linux内核中还保留了这个概念，并仍然用它来代表文件系统中的一些所谓的元数据，但是由于已经没有buffer了，那么free该怎么显示buffers呢？内核巧妙的利用了一个特性，那就是文件系统在读取元数据的时候一般都是通过它所对应的块设备来进行，也就是说元数据存储的page一般都是保存在块设备对应的tree中，而一般文件的page  cache则是保存在它的宿主文件的tree中。有了这个假设，我们就可以通过统计所有在块设备的tree上的page来得出系统的buffers数量。