‘壹’ 面试 linux 文件系统怎样io到底层
前言：本文主要讲解LinuxIO调度层的三种模式：cfp、deadline和noop，并给出各自的优化和适用场景建议。IO调度发生在Linux内核的IO调度层。这个层次是针对Linux的整体IO层次体系来说的。从read()或者write()系统调用的角度来说，Linux整体IO体系可以分为七层，它们分别是：VFS层：虚拟文件系统层。由于内核要跟多种文件系统打交道，而每一种文件系统所实现的数据结构和相关方法都可能不尽相同，所以，内核抽象了这一层，专门用来适配各种文件系统，并对外提供统一操作接口。文件系统层：不同的文件系统实现自己的操作过程，提供自己特有的特征，具体不多说了，大家愿意的话自己去看代码即可。页缓存层：负责真对page的缓存。通用块层：由于绝大多数情况的io操作是跟块设备打交道，所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备，对上提供统一的BlockIO请求标准。IO调度层：因为绝大多数的块设备都是类似磁盘这样的设备，所以有必要根据这类设备的特点以及应用的不同特点来设置一些不同的调度算法和队列。以便在不同的应用环境下有针对性的提高磁盘的读写效率，这里就是大名鼎鼎的Linux电梯所起作用的地方。针对机械硬盘的各种调度方法就是在这实现的。块设备驱动层：驱动层对外提供相对比较高级的设备操作接口，往往是C语言的，而下层对接设备本身的操作方法和规范。块设备层：这层就是具体的物理设备了，定义了各种真对设备操作方法和规范。有一个已经整理好的[LinuxIO结构图]，非常经典，一图胜千言：我们今天要研究的内容主要在IO调度这一层。它要解决的核心问题是，如何提高块设备IO的整体性能？这一层也主要是针对机械硬盘结构而设计的。众所周知，机械硬盘的存储介质是磁盘，磁头在盘片上移动进行磁道寻址，行为类似播放一张唱片。这种结构的特点是，顺序访问时吞吐量较高，但是如果一旦对盘片有随机访问，那么大量的时间都会浪费在磁头的移动上，这时候就会导致每次IO的响应时间变长，极大的降低IO的响应速度。磁头在盘片上寻道的操作，类似电梯调度，实际上在最开始的时期，Linux把这个算法命名为Linux电梯算法，即：如果在寻道的过程中，能把顺序路过的相关磁道的数据请求都“顺便”处理掉，那么就可以在比较小影响响应速度的前提下，提高整体IO的吞吐量。这就是我们为什么要设计IO调度算法的原因。目前在内核中默认开启了三种算法/模式：noop，cfq和deadline。严格算应该是两种：因为第一种叫做noop，就是空操作调度算法，也就是没有任何调度操作，并不对io请求进行排序，仅仅做适当的io合并的一个fifo队列。目前内核中默认的调度算法应该是cfq，叫做完全公平队列调度。这个调度算法人如其名，它试图给所有进程提供一个完全公平的IO操作环境。注：请大家一定记住这个词语，cfq，完全公平队列调度，不然下文就没法看了。cfq为每个进程创建一个同步IO调度队列，并默认以时间片和请求数限定的方式分配IO资源，以此保证每个进程的IO资源占用是公平的，cfq还实现了针对进程级别的优先级调度，这个我们后面会详细解释。查看和修改IO调度算法的方法是：cfq是通用服务器比较好的IO调度算法选择，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适应，尤其是IO压力集中在某些进程上的场景。因为这种场景我们需要的满足某个或者某几个进程的IO响应速度，而不是让所有的进程公平的使用IO，比如数据库应用。deadline调度（最终期限调度）就是更适合上述场景的解决方案。deadline实现了四个队列：其中两个分别处理正常read和write，按扇区号排序，进行正常io的合并处理以提高吞吐量。因为IO请求可能会集中在某些磁盘位置，这样会导致新来的请求一直被合并，可能会有其他磁盘位置的io请求被饿死。另外两个处理超时read和write的队列，按请求创建时间排序，如果有超时的请求出现，就放进这两个队列，调度算法保证超时（达到最终期限时间）的队列中的请求会优先被处理，防止请求被饿死。不久前，内核还是默认标配四种算法，还有一种叫做as的算法（Anticipatoryscheler），预测调度算法。一个高大上的名字，搞得我一度认为Linux内核都会算命了。结果发现，无非是在基于deadline算法做io调度的之前等一小会时间，如果这段时间内有可以合并的io请求到来，就可以合并处理，提高deadline调度的在顺序读写情况下的数据吞吐量。其实这根本不是啥预测，我觉得不如叫撞大运调度算法，当然这种策略在某些特定场景差效果不错。但是在大多数场景下，这个调度不仅没有提高吞吐量，还降低了响应速度，所以内核干脆把它从默认配置里删除了。毕竟Linux的宗旨是实用，而我们也就不再这个调度算法上多费口舌了。1、cfq：完全公平队列调度cfq是内核默认选择的IO调度队列，它在桌面应用场景以及大多数常见应用场景下都是很好的选择。如何实现一个所谓的完全公平队列（CompletelyFairQueueing）？首先我们要理解所谓的公平是对谁的公平？从操作系统的角度来说，产生操作行为的主体都是进程，所以这里的公平是针对每个进程而言的，我们要试图让进程可以公平的占用IO资源。那么如何让进程公平的占用IO资源？我们需要先理解什么是IO资源。当我们衡量一个IO资源的时候，一般喜欢用的是两个单位，一个是数据读写的带宽，另一个是数据读写的IOPS。带宽就是以时间为单位的读写数据量，比如，100Mbyte/s。而IOPS是以时间为单位的读写次数。在不同的读写情境下，这两个单位的表现可能不一样，但是可以确定的是，两个单位的任何一个达到了性能上限，都会成为IO的瓶颈。从机械硬盘的结构考虑，如果读写是顺序读写，那么IO的表现是可以通过比较少的IOPS达到较大的带宽，因为可以合并很多IO，也可以通过预读等方式加速数据读取效率。当IO的表现是偏向于随机读写的时候，那么IOPS就会变得更大，IO的请求的合并可能性下降，当每次io请求数据越少的时候，带宽表现就会越低。从这里我们可以理解，针对进程的IO资源的主要表现形式有两个：进程在单位时间内提交的IO请求个数和进程占用IO的带宽。其实无论哪个，都是跟进程分配的IO处理时间长度紧密相关的。有时业务可以在较少IOPS的情况下占用较大带宽，另外一些则可能在较大IOPS的情况下占用较少带宽，所以对进程占用IO的时间进行调度才是相对最公平的。即，我不管你是IOPS高还是带宽占用高，到了时间咱就换下一个进程处理，你爱咋样咋样。所以，cfq就是试图给所有进程分配等同的块设备使用的时间片，进程在时间片内，可以将产生的IO请求提交给块设备进行处理，时间片结束，进程的请求将排进它自己的队列，等待下次调度的时候进行处理。这就是cfq的基本原理。当然，现实生活中不可能有真正的“公平”，常见的应用场景下，我们很肯能需要人为的对进程的IO占用进行人为指定优先级，这就像对进程的CPU占用设置优先级的概念一样。所以，除了针对时间片进行公平队列调度外，cfq还提供了优先级支持。每个进程都可以设置一个IO优先级，cfq会根据这个优先级的设置情况作为调度时的重要参考因素。优先级首先分成三大类：RT、BE、IDLE，它们分别是实时（RealTime）、最佳效果（BestTry）和闲置（Idle）三个类别，对每个类别的IO，cfq都使用不同的策略进行处理。另外，RT和BE类别中，分别又再划分了8个子优先级实现更细节的QOS需求，而IDLE只有一个子优先级。另外，我们都知道内核默认对存储的读写都是经过缓存（buffer/cache）的，在这种情况下，cfq是无法区分当前处理的请求是来自哪一个进程的。只有在进程使用同步方式（syncread或者syncwirte）或者直接IO（DirectIO）方式进行读写的时候，cfq才能区分出IO请求来自哪个进程。所以，除了针对每个进程实现的IO队列以外，还实现了一个公共的队列用来处理异步请求。当前内核已经实现了针对IO资源的cgroup资源隔离，所以在以上体系的基础上，cfq也实现了针对cgroup的调度支持。总的来说，cfq用了一系列的数据结构实现了以上所有复杂功能的支持，大家可以通过源代码看到其相关实现，文件在源代码目录下的block/cfq-iosched.c。1.1cfq设计原理在此，我们对整体数据结构做一个简要描述：首先，cfq通过一个叫做cfq_data的数据结构维护了整个调度器流程。在一个支持了cgroup功能的cfq中，全部进程被分成了若干个contralgroup进行管理。每个cgroup在cfq中都有一个cfq_group的结构进行描述，所有的cgroup都被作为一个调度对象放进一个红黑树中，并以vdisktime为key进行排序。vdisktime这个时间纪录的是当前cgroup所占用的io时间，每次对cgroup进行调度时，总是通过红黑树选择当前vdisktime时间最少的cgroup进行处理，以保证所有cgroups之间的IO资源占用“公平”。当然我们知道，cgroup是可以对blkio进行资源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime时间增长较慢，分配比例小的vdisktime时间增长较快，快慢与分配比例成正比。这样就做到了不同的cgroup分配的IO比例不一样，并且在cfq的角度看来依然是“公平“的。选择好了需要处理的cgroup（cfq_group）之后，调度器需要决策选择下一步的service_tree。service_tree这个数据结构对应的都是一系列的红黑树，主要目的是用来实现请求优先级分类的，就是RT、BE、IDLE的分类。每一个cfq_group都维护了7个service_trees，其定义如下：其中service_tree_idle就是用来给IDLE类型的请求进行排队用的红黑树。而上面二维数组，首先第一个维度针对RT和BE分别各实现了一个数组，每一个数组中都维护了三个红黑树，分别对应三种不同子类型的请求，分别是：SYNC、SYNC_NOIDLE以及ASYNC。我们可以认为SYNC相当于SYNC_IDLE并与SYNC_NOIDLE对应。idling是cfq在设计上为了尽量合并连续的IO请求以达到提高吞吐量的目的而加入的机制，我们可以理解为是一种“空转”等待机制。空转是指，当一个队列处理一个请求结束后，会在发生调度之前空等一小会时间，如果下一个请求到来，则可以减少磁头寻址，继续处理顺序的IO请求。为了实现这个功能，cfq在service_tree这层数据结构这实现了SYNC队列，如果请求是同步顺序请求，就入队这个servicetree，如果请求是同步随机请求，则入队SYNC_NOIDLE队列，以判断下一个请求是否是顺序请求。所有的异步写操作请求将入队ASYNC的servicetree，并且针对这个队列没有空转等待机制。此外，cfq还对SSD这样的硬盘有特殊调整，当cfq发现存储设备是一个ssd硬盘这样的队列深度更大的设备时，所有针对单独队列的空转都将不生效，所有的IO请求都将入队SYNC_NOIDLE这个servicetree。每一个servicetree都对应了若干个cfq_queue队列，每个cfq_queue队列对应一个进程，这个我们后续再详细说明。cfq_group还维护了一个在cgroup内部所有进程公用的异步IO请求队列，其结构如下：异步请求也分成了RT、BE、IDLE这三类进行处理，每一类对应一个cfq_queue进行排队。BE和RT也实现了优先级的支持，每一个类型有IOPRIO_BE_NR这么多个优先级，这个值定义为8，数组下标为0-7。我们目前分析的内核代码版本为Linux4.4，可以看出，从cfq的角度来说，已经可以实现异步IO的cgroup支持了，我们需要定义一下这里所谓异步IO的含义，它仅仅表示从内存的buffer/cache中的数据同步到硬盘的IO请求，而不是aio(man7aio)或者linux的native异步io以及lio机制，实际上这些所谓的“异步”IO机制，在内核中都是同步实现的（本质上冯诺伊曼计算机没有真正的“异步”机制）。我们在上面已经说明过，由于进程正常情况下都是将数据先写入buffer/cache，所以这种异步IO都是统一由cfq_group中的async请求队列处理的。那么为什么在上面的service_tree中还要实现和一个ASYNC的类型呢？这当然是为了支持区分进程的异步IO并使之可以“完全公平”做准备喽。实际上在最新的cgroupv2的blkio体系中，内核已经支持了针对bufferIO的cgroup限速支持，而以上这些可能容易混淆的一堆类型，都是在新的体系下需要用到的类型标记。新体系的复杂度更高了，功能也更加强大，但是大家先不要着急，正式的cgroupv2体系，在Linux4.5发布的时候会正式跟大家见面。我们继续选择service_tree的过程，三种优先级类型的service_tree的选择就是根据类型的优先级来做选择的，RT优先级最高，BE其次，IDLE最低。就是说，RT里有，就会一直处理RT，RT没了再处理BE。每个service_tree对应一个元素为cfq_queue排队的红黑树，而每个cfq_queue就是内核为进程（线程）创建的请求队列。每一个cfq_queue都会维护一个rb_key的变量，这个变量实际上就是这个队列的IO服务时间（servicetime）。这里还是通过红黑树找到servicetime时间最短的那个cfq_queue进行服务，以保证“完全公平”。选择好了cfq_queue之后，就要开始处理这个队列里的IO请求了。这里的调度方式基本跟deadline类似。cfq_queue会对进入队列的每一个请求进行两次入队，一个放进fifo中，另一个放进按访问扇区顺序作为key的红黑树中。默认从红黑树中取请求进行处理，当请求的延时时间达到deadline时，就从红黑树中取等待时间最长的进行处理，以保证请求不被饿死。这就是整个cfq的调度流程，当然其中还有很多细枝末节没有交代，比如合并处理以及顺序处理等等。1.2cfq的参数调整理解整个调度流程有助于我们决策如何调整cfq的相关参数。所有cfq的可调参数都可以在/sys/class/block/sda/queue/iosched/目录下找到，当然，在你的系统上，请将sda替换为相应的磁盘名称。我们来看一下都有什么：这些参数部分是跟机械硬盘磁头寻道方式有关的，如果其说明你看不懂，请先补充相关知识：back_seek_max:磁头可以向后寻址的最大范围，默认值为16M。back_seek_penalty:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的。以上两个是为了防止磁头寻道发生抖动而导致寻址过慢而设置的。基本思路是这样，一个io请求到来的时候，cfq会根据其寻址位置预估一下其磁头寻道成本。设置一个最大值back_seek_max，对于请求所访问的扇区号在磁头后方的请求，只要寻址范围没有超过这个值，cfq会像向前寻址的请求一样处理它。再设置一个评估成本的系数back_seek_penalty，相对于磁头向前寻址，向后寻址的距离为1/2(1/back_seek_penalty)时，cfq认为这两个请求寻址的代价是相同。这两个参数实际上是cfq判断请求合并处理的条件限制，凡事复合这个条件的请求，都会尽量在本次请求处理的时候一起合并处理。fifo_expire_async:设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理。fifo_expire_sync:这个参数跟上面的类似，区别是用来设置同步请求的超时时间。slice_idle:参数设置了一个等待时间。这让cfq在切换cfq_queue或servicetree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者servicetree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能。group_idle:这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle＝0而group_idle＝8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生。low_latency:这个是用来开启或关闭cfq的低延时（lowlatency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slicetime）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的。我们已经知道cfq设计上有“空转”（idling）这个概念，目的是为了可以让连续的读写操作尽可能多的合并处理，减少磁头的寻址操作以便增大吞吐量。如果有进程总是很快的进行顺序读写，那么它将因为cfq的空转等待命中率很高而导致其它需要处理IO的进程响应速度下降，如果另一个需要调度的进程不会发出大量顺序IO行为的话，系统中不同进程IO吞吐量的表现就会很不均衡。就比如，系统内存的cache中有很多脏页要写回时，桌面又要打开一个浏览器进行操作，这时脏页写回的后台行为就很可能会大量命中空转时间，而导致浏览器的小量IO一直等待，让用户感觉浏览器运行响应速度变慢。这个low_latency主要是对这种情况进行优化的选项，当其打开时，系统会根据target_latency的配置对因为命中空转而大量占用IO吞吐量的进程进行限制，以达到不同进程IO占用的吞吐量的相对均衡。这个开关比较合适在类似桌面应用的场景下打开。target_latency:当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度。quantum:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效。slice_sync:当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为：time_slice=slice_sync+(slice_sync/5*(4-prio))。这个参数对同步请求有效。slice_async:这个值跟上一个类似，区别是对异步请求有效。slice_async_rq:这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关。1.3cfq的IOPS模式我们已经知道，默认情况下cfq是以时间片方式支持的带优先级的调度来保证IO资源占用的公平。高优先级的进程将得到的时间片长度，而低优先级的进程时间片相对较小。当我们的存储是一个高速并且支持NCQ（原生指令队列）的设备的时候，我们最好可以让其可以从多个cfq队列中处理多路的请求，以便提升NCQ的利用率。此时使用时间片的分配方式分配资源就显得不合时宜了，因为基于时间片的分配，同一时刻最多能处理的请求队列只有一个。这时，我们需要切换cfq的模式为IOPS模式。切换方式很简单，就是将slice_idle=0即可。内核会自动检测你的存储设备是否支持NCQ，如果支持的话cfq会自动切换为IOPS模式。另外，在默认的基于优先级的时间片方式下，我们可以使用ionice命令来调整进程的IO优先级。进程默认分配的IO优先级是根据进程的nice值计算而来的，计算方法可以在manionice中看到，这里不再废话。2、deadline：最终期限调度deadline调度算法相对cfq要简单很多。其设计目标是：在保证请求按照设备扇区的顺序进行访问的同时，兼顾其它请求不被饿死，要在一个最终期限前被调度到。我们知道磁头对磁盘的寻道是可以进行顺序访问和随机访问的，因为寻道延时时间的关系，顺序访问时IO的吞吐量更大，随机访问的吞吐量小。如果我们想为一个机械硬盘进行吞吐量优化的话，那么就可以让调度器按照尽量复合顺序访问的IO请求进行排序，之后请求以这样的顺序发送给硬盘，就可以使IO的吞吐量更大。但是这样做也有另一个问题，就是如果此时出现了一个请求，它要访问的磁道离目前磁头所在磁道很远，应用的请求又大量集中在目前磁道附近。导致大量请求一直会被合并和插队处理，而那个要访问比较远磁道的请求将因为一直不能被调度而饿死。deadline就是这样一种调度器，能在保证IO最大吞吐量的情况下，尽量使远端请求在一个期限内被调度而不被饿死的调度器。
‘贰’ linux怎么计算io读写速度
Linux下测试磁盘的读写IO速度，使用hdparm命令，下面是测试方法：
#hdparm-Tt/dev/sda
/dev/sda:
Timingcachedreads:6676MBin2.00seconds=3340.18MB/sec
Timingbuffereddiskreads:218MBin3.11seconds=70.11MB/sec
#可以看到，2秒钟读取了6676MB的缓存，约合3340.18MB/sec；
#在3.11秒中读取了218MB磁盘(物理读)，读取速度约合70.11MB/sec；
‘叁’ Linux中常见IO调度器
对于磁盘I/O，Linux提供了cfq, deadline和noop三种调度策略
考虑到硬件配置、实际应用场景（读写比例、顺序还是随机读写）的差异，上面的简单解释对于实际选择没有太大帮助，实际该选择哪个基本还是要实测来验证。不过下面几条说明供参考：
NOOP全称No Operation,中文名称电梯式调度器，该算法实现了最简单的FIFO队列，所有I/O请求大致按照先来后到的顺序进行操作。NOOP实现了一个简单的FIFO队列,它像电梯的工作方式一样对I/O请求进行组织。它是基于先入先出（FIFO）队列概念的 Linux 内核里最简单的I/O 调度器。此调度程序最适合于固态硬盘。
Deadline翻译成中文是截止时间调度器，是对Linus Elevator的一种改进，它避免有些请求太长时间不能被处理。另外可以区分对待读操作和写操作。DEADLINE额外分别为读I/O和写I/O提供了FIFO队列。
Deadline对读写request进行了分类管理，并且在调度处理的过程中读请求具有较高优先级。这主要是因为读请求往往是同步操作，对延迟时间比较敏感，而写操作往往是异步操作，可以尽可能的将相邻访问地址的请求进行合并，但是，合并的效率越高，延迟时间会越长。因此，为了区别对待读写请求类型，deadline采用两条链表对读写请求进行分类管理。但是，引入分类管理之后，在读优先的情况下，写请求如果长时间得到不到调度，会出现饿死的情况，因此，deadline算法考虑了写饿死的情况，从而保证在读优先调度的情况下，写请求不会被饿死。
总体来讲，deadline算法对request进行了优先权控制调度，主要表现在如下几个方面：
CFQ全称Completely Fair Scheler ，中文名称完全公平调度器，它是现在许多 Linux 发行版的默认调度器，CFQ是内核默认选择的I/O调度器。它将由进程提交的同步请求放到多个进程队列中，然后为每个队列分配时间片以访问磁盘。 对于通用的服务器是最好的选择，CFQ均匀地分布对I/O带宽的访问 。CFQ为每个进程和线程，单独创建一个队列来管理该进程所产生的请求,以此来保证每个进程都能被很好的分配到I/O带宽，I/O调度器每次执行一个进程的4次请求。该算法的特点是按照I/O请求的地址进行排序，而不是按照先来后到的顺序来进行响应。简单来说就是给所有同步进程分配时间片，然后才排队访问磁盘。
多队列无操作I / O调度程序。不对请求进行重新排序，最小的开销。NVME等快速随机I / O设备的理想选择。
这是对最后期限I / O调度程序的改编，但设计用于 多队列设备。一个出色的多面手，CPU开销相当低。
‘肆’ Linux的五种IO模型
在linux中，对于一次读取IO请求（不仅仅是磁盘，还有网络）的操作，数据并不会直接拷贝到用户程序的用户空间缓冲区。它首先会被拷贝到操作系统的内核空间，然后才会从操作系统内核的缓冲区拷贝到用户空间的缓冲区。
大概是这个样子。
从图中可以看见，这是分四步进行的，而这四步里面有些细节，就有了这5种IO模型
前四种为同步IO，后一种为异步IO，什么是同步异步可以看看我之前写的 同步与异步，阻塞与非阻塞 。
应用进程发起系统调用后就阻塞了，直到内核buffer拷贝到用户buffer，发出成功提示后才继续执行。
适用场景：并发量小的要及时响应的网络应用开发，JavaBIO。
优点：易于开发，不消耗CPU资源（线程阻塞），及时响应。
缺点：不适用与并发量大的网络应用开发，一个请求一个线程，系统开销大。
应用进程发起系统调用，内核立马返回一个自己当前的缓冲区的状态（错误或者说成功），假如
为错误则隔段时间再系统调用（轮询），直到返回成功为止。另外再说一点，有人说轮询之间可以设置一个时间，例如每几秒执行一次，然后在这段期间程序可以干自己的事情。（这个我不清楚是不是，虽然理论上可以实现，但是我觉得第一种与第二种的区别应该强调的是是否放弃CPU，第二种有点CAS+轮询这种轻量级锁的感觉，第一种就是那种重量级锁的感觉）。
适用场景：并发量小且不用技术响应的网络应用开发
优点：易于开发，可以在轮询的间断期间继续执行程序。
缺点：不适用与并发量大的网络应用开发，一个请求一个线程，系统开销大。消耗CPU资源（轮询），不及时响应。
将多个IO注册到一个复用器上（select，poll，epoll），然后一个进程监视所有注册进来的IO。
进程阻塞在select上，而不是真正阻塞在IO系统调用上。当其中任意一个注册的IO的内核缓冲区有了数据，select就会返回（告诉程序内核态缓存有数据了），然后用户进程再发起调用，数据就从内核态buffer转到用态buffer（这段期间也是要阻塞的）。
适用场景：并发量大且对响应要求较为高的网络应用开发，JavaNIO
优点：将阻塞从多个进程转移到了一个select调用身上，假如并发量大的话select调用是不易被阻塞的，或者说阻塞时间短的。
缺点：不易开发，实现难度大，当并发量小的时候还不如同步阻塞模型。
应用程序向内核注册一个信号处理程序，然后立即返回，当数据准备好了以后（数据到了内核buffer），内核个应用进程一个信号，然后应用进程通过信号处理程序发起系统调用，然后阻塞直达数据从内核buffer复制到用户buffer。
优点：将阻塞从多个进程转移到了一个select调用身上，假如并发量大的话select调用是不易被阻塞的，或者说阻塞时间短的。
缺点：不易开发，实现难度大。
以上四个IO模型都可以看出来，到最后用户进程都要在数据从内核buffer复制到用户buffer时阻塞，直到内核告诉进程准备成功。这就是同步进程，就是发出一个功能调用时，在没有得到结果之前，该调用就不返回或继续执行后续操作。
就是发出一个功能调用时，在没有得到结果之前，该调用就不返回或继续执行后续操作
这个就是直到数据完成到用户buffer才通知。
应用场景：Java AIO，适合高性能高并发应用。
优点：不阻塞，减少了线程切换，
缺点：难以实现，要操作系统支持。
‘伍’ Linux 磁盘IO
磁盘结构与数据存储方式, 数据是如何存储的，又通过怎样的方式被访问？
机械硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成；数据就存放在磁盘盘片中
现代硬盘寻道都是采用CHS( Cylinder Head Sector )的方式，硬盘读取数据时，读写磁头沿径向移动，移到要读取的扇区所在磁道的上方，这段时间称为 寻道时间(seek time) 。 因读写磁头的起始位置与目标位置之间的距离不同，寻道时间也不同 。磁头到达指定磁道后，然后通过盘片的旋转，使得要读取的扇区转到读写磁头的下方，这段时间称为 旋转延迟时间(rotational latencytime) 。然后再读写数据，读写数据也需要时间，这段时间称为 传输时间(transfer time) 。
固态硬盘主要由主控芯片、闪存颗粒与缓存组成；数据就存放在闪存芯片中
通过主控芯片进行寻址， 因为是电信号方式， 没有任何物理结构， 所以寻址速度非常快且与数据存储位置无关
如何查看系统IO状态
查看磁盘空间
调用 open , fwrite 时到底发生了什么?
在一个IO过程中，以下5个API/系统调用是必不可少的
Create 函数用来打开一个文件，如果该文件不存在，那么需要在磁盘上创建该文件
Open 函数用于打开一个指定的文件。如果在 Open 函数中指定 O_CREATE 标记，那么 Open 函数同样可以实现 Create 函数的功能
Clos e函数用于释放文件句柄
Write 和 Read 函数用于实现文件的读写过程
O_SYNC (先写缓存, 但是需要实际落盘之后才返回, 如果接下来有读请求, 可以从内存读 ), write-through
O_DSYNC (D=data, 类似O_SYNC, 但是只同步数据, 不同步元数据)
O_DIRECT (直接写盘, 不经过缓存)
O_ASYNC (异步IO, 使用信号机制实现, 不推荐, 直接用aio_xxx)
O_NOATIME (读取的时候不更新文件 atime(access time))
sync() 全局缓存写回磁盘
fsync() 特定fd的sync()
fdatasync() 只刷数据, 不同步元数据
mount noatime(全局不记录atime), re方式(只读), sync(同步方式)
一个IO的传奇一生 这里有一篇非常好的资料，讲述了整个IO过程；
下面简单记录下自己的理解的一次常见的Linux IO过程， 想了解更详细及相关源码，非常推荐阅读上面的原文
Linux IO体系结构
[站外图片上传中...(image-38a7b-1644137945193)]
Superblock 超级描述了整个文件系统的信息。为了保证可靠性，可以在每个块组中对superblock进行备份。为了避免superblock冗余过多，可以采用稀疏存储的方式，即在若干个块组中对superblock进行保存，而不需要在所有的块组中都进行备份
GDT 组描述符表 组描述符表对整个组内的数据布局进行了描述。例如，数据块位图的起始地址是多少？inode位图的起始地址是多少？inode表的起始地址是多少？块组中还有多少空闲块资源等。组描述符表在superblock的后面
数据块位图 数据块位图描述了块组内数据块的使用情况。如果该数据块已经被某个文件使用，那么位图中的对应位会被置1，否则该位为0
Inode位图 Inode位图描述了块组内inode资源使用情况。如果一个inode资源已经使用，那么对应位会被置1
Inode表 （即inode资源）和数据块。这两块占据了块组内的绝大部分空间，特别是数据块资源
一个文件是由inode进行描述的。一个文件占用的数据块block是通过inode管理起来的 。在inode结构中保存了直接块指针、一级间接块指针、二级间接块指针和三级间接块指针。对于一个小文件，直接可以采用直接块指针实现对文件块的访问；对于一个大文件，需要采用间接块指针实现对文件块的访问
最简单的调度器。它本质上就是一个链表实现的 fifo 队列，并对请求进行简单的 合并 处理。
调度器本身并没有提供任何可以配置的参数
读写请求被分成了两个队列， 一个用访问地址作为索引，一个用进入时间作为索引，并且采用两种方式将这些request管理起来；
在请求处理的过程中，deadline算法会优先处理那些访问地址临近的请求，这样可以最大程度的减少磁盘抖动的可能性。
只有在有些request即将被饿死的时候，或者没有办法进行磁盘顺序化操作的时候，deadline才会放弃地址优先策略，转而处理那些即将被饿死的request
deadline算法可调整参数
read_expire : 读请求的超时时间设置(ms)。当一个读请求入队deadline的时候，其过期时间将被设置为当前时间＋read_expire，并放倒fifo_list中进行排序
write_expire :写请求的超时时间设置(ms)
fifo_batch :在顺序（sort_list）请求进行处理的时候，deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中，不会产生是否超时的检查，也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾，当饥饿时间需要尽可能的符合预期的时候，我们可以调小这个值，以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量，但是会导致处理饥饿请求的延时变长
writes_starved :这个值是在上述deadline出队处理第一步时做检查用的。用来判断当读队列不为空时，写队列的饥饿程度是否足够高，以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候，deadline并不会立即对写请求进行处理，而是给相关数据结构中的starved进行累计，如果这是第一次检查到有写请求进行处理，那么这个计数就为1。如果此时writes_starved值为2，则我们认为此时饥饿程度还不足够高，所以继续处理读请求。只有当starved >= writes_starved的时候，deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的，这个值越大，则写请求越被滞后处理，越小，写请求就越可以获得趋近于读请求的优先级
front_merges :当一个新请求进入队列的时候，如果其请求的扇区距离当前扇区很近，那么它就是可以被合并处理的。而这个合并可能有两种情况，一个是向当前位置后合并，另一种是向前合并。在某些场景下，向前合并是不必要的，那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并，设置为0关闭
在调度一个request时，首先需要选择一个一个合适的cfq_group。Cfq调度器会为每个cfq_group分配一个时间片，当这个时间片耗尽之后，会选择下一个cfq_group。每个cfq_group都会分配一个vdisktime，并且通过该值采用红黑树对cfq_group进行排序。在调度的过程中，每次都会选择一个vdisktime最小的cfq_group进行处理。
一个cfq_group管理了7棵service tree，每棵service tree管理了需要调度处理的对象cfq_queue。因此，一旦cfq_group被选定之后，需要选择一棵service tree进行处理。这7棵service tree被分成了三大类，分别为RT、BE和IDLE。这三大类service tree的调度是按照优先级展开的
通过优先级可以很容易的选定一类Service tree。当一类service tree被选定之后，采用service time的方式选定一个合适的cfq_queue。每个Service tree是一棵红黑树，这些红黑树是按照service time进行检索的，每个cfq_queue都会维护自己的service time。分析到这里，我们知道，cfq算法通过每个cfq_group的vdisktime值来选定一个cfq_group进行服务，在处理cfq_group的过程通过优先级选择一个最需要服务的service tree。通过该Service tree得到最需要服务的cfq_queue。该过程在 cfq_select_queue 函数中实现
一个cfq_queue被选定之后，后面的过程和deadline算法有点类似。在选择request的时候需要考虑每个request的延迟等待时间，选择那种等待时间最长的request进行处理。但是，考虑到磁盘抖动的问题，cfq在处理的时候也会进行顺序批量处理，即将那些在磁盘上连续的request批量处理掉
cfq调度算法的参数
back_seek_max :磁头可以向后寻址的最大范围，默认值为16M
back_seek_penalty :向后寻址的惩罚系数。这个值是跟向前寻址进行比较的
fifo_expire_async :设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理
fifo_expire_sync :这个参数跟上面的类似，区别是用来设置同步请求的超时时间
slice_idle :参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能
group_idle :这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生
low_latency :这个是用来开启或关闭cfq的低延时（low latency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的
target_latency :当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度
quantum :这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效
slice_sync :当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 这个参数对同步请求有效
slice_async :这个值跟上一个类似，区别是对异步请求有效
slice_async_rq :这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关
通常在Linux上使用的IO接口是同步方式的，进程调用 write / read 之后会阻塞陷入到内核态，直到本次IO过程完成之后，才能继续执行，下面介绍的异步IO则没有这种限制，但是当前Linux异步IO尚未成熟
目前Linux aio还处于较不成熟的阶段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是无法使用默认的Page Cache机制
正常情况下，使用aio族接口的简要方式如下：
io_uring 是 2019 年 5 月发布的 Linux 5.1 加入的一个重大特性 —— Linux 下的全新的异步 I/O 支持，希望能彻底解决长期以来 Linux AIO 的各种不足
io_uring 实现异步 I/O 的方式其实是一个生产者-消费者模型:
逻辑卷管理
RAID0
RAID1
RAID5（纠错）
条带化
Linux系统性能调整：IO过程
Linux的IO调度
一个IO的传奇一生
理解inode
Linux 文件系统是怎么工作的？
Linux中Buffer cache性能问题一探究竟
Asynchronous I/O and event notification on linux
AIO 的新归宿：io_uring
Linux 文件 I/O 进化史（四）：io_uring —— 全新的异步 I/O
‘陆’ Linux磁盘I/O子系统
上文学到 不管什么文件系统类型，都通过VFS(虚拟文件系统层)读和写等操作文件，写文件的元数据和文件的实际数据到磁盘 。但数据是怎么落地磁盘中的呢？落到磁盘中的都经过什么组件？
以一个写数据到磁盘为例，给出Linux I/O子系统的体系结构。
当磁盘执行写入操作时发生的 基本操作 (假设磁盘上扇区中的文件数据已经被读取到分页缓存)。
1) 一个进程通过write()系统调用 VFS虚拟文件系统 请求写一个文件。
2) 内核更新已映射文件的分页缓存。
3) 内核线程 pdflush/Per-BDI flush将分页缓存刷新到磁盘。
4) 同时 VFS虚拟文件系统层 在一个bio(block input output)结构中放置每个块缓冲，并向块设备层提交写请求。
5) 块设备层 从上层得到请求，并执行一个 I/O电梯操作，将请求放置到I/O 请求队列。
6) 设备驱动器 （比如SCSI 或 其他设备特定的驱动器）将执行写操作。
7) 磁盘设备 固件执行硬件操作，如在盘片扇区上定位磁头，旋转，数据传输。
过去的20年中，处理器性能的改进要超过计算机系统中的其他组件，如处理器缓存、物理内存及磁盘等等。 访问内存和磁盘的速度较慢会限制整个系统的性能 ，怎么解决这个问题呢？引入 磁盘缓存机制 ，在较快的存储器中缓存频繁使用的数据，减少了访问较慢的存储器的次数。
磁盘缓存机制有以下3个地方解决：
引入存储层次结构 ，在CPU和磁盘之间放置L1缓存、L2缓存、物理内存和一些其他缓存减少这种不匹配，从而让进程减少访问较慢的内存和磁盘的次数，避免CPU花费更多的时间等待来自较慢磁盘驱动器的数据。
另外一种解决思路： 在更快的存储器上实现更高的缓存命中率，就可能更快地访问数据 。怎么提高缓存命中率呢？引入 参考局部性(locality of reference) 的技术。这项技术基于以下2个原则：
1) 大多数最近使用过的数据，在不久的将来有较高的几率被再次使用(时间局部性)。
2) 驻留在数据附近的数据有较高的几率被再次使用(空间局部性)。
Linux在许多组件中使用这些原则，比如分页缓存、文件对象缓存（索引节点缓存、目录条目缓存等等）、预读缓冲等。
以进程从磁盘读取数据并将数据复制到内存的过程为例。进程可以从缓存在内存中的数据副本中检索相同的数据，用于读和写。
1) 进程写入新数据
当一个进程试图改变数据时，进程首先在内存中改变数据。此时磁盘上的数据和内存中的数据是不相同的，并且内存中的数据被称为 脏页(dirty page) 。脏页中的数据应该尽快被同步到磁盘上，因为如果系统突然发生崩溃(电源故障)则内存中的数据会丢失。
2) 将内存中的数据刷新到磁盘
同步脏数据缓冲的过程被称为 刷新 。在Linux 2.6.32内核之前(Red Hat Enterprise Linux 5)，通过内核线程pdflush将脏页数据刷新到磁盘。在Linux 2.6.32内核中(Red Hat Enterprise Linux 6.x)pdflush被Per-BDI flush线程(BDI=Backing Device Interface)取代，Per-BDI flush线程以flush-MAJOR：MINOR的形式出现在进程列表中。当内存中脏页比例超过阀值时，就会发生刷新(flush)。
块层处理所有与块设备操作相关的活动。块层中的关键数据结构是bio(block input output)结构，bio结构是在虚拟文件系统层和块层之间的一个接口。
当执行写的时候，虚拟文件系统层试图写入由块缓冲区构成的页缓存，将连续的块放置在一起构成bio结构，然后将其发送到块层。
块层处理bio请求，并链接这些请求进入一个被称为I/O请求的队列。这个链接的操作被称为 I/O电梯调度(I/O elevator)。问个问题：为啥叫电梯调度呢？
Linux 2.4内核使用的是一种单一的通用I/O电梯调度方法，2.6内核提供4种电梯调度算法供用户自己选择。因为Linux操作系统适用的场合很广泛，所以I/O设备和工作负载特性都会有明显的变化。
1）CFQ(Complete Fair Queuing，完全公平队列)
CFQ电梯调度为每个进程维护一个I/O队列，从而 对进程实现一个QoS(服务质量)策略 。CFQ电梯调度能够很好地适应存在很多竞争进程的大型多用户系统。它积极地避免进程饿死并具有低延迟特征。从2.6.18内核发行版开始，CFQ电梯调度成为默认I/O调度器。
CFQ为每个进程/线程单独创建一个队列来管理产生的请求，各队列之间用时间片来调度，以保证每个进程都能分配到合适的I/O带宽。I/O调度器每次执行一个进程的4个请求。
2）Deadline
Deadline是一种循环的电梯调度(round robin)方法，Deadline 算法实现了一个近似于实时的I/O子系统。在保持良好的磁盘吞吐量的同时，Deadline电梯调度既提供了出色的块设备扇区的顺序访问，又确保一个进程不会在队列中等待太久导致饿死。
Deadline调度器为了兼顾这两个方面，引入了4个队列，这4个队列可分为两类，每一类都由读和写两种队列组成。一类队列用来对 请求 按 起始扇区序号 进行排序（通过红黑树来组织），称为sort_list；另一类对 请求 按 生成时间进行排序 （由链表来组织），称为fifo_list。每当确定了一个传输方向（读或写），系统都将会从相应的sort_list中将一批连续请求调度到请求队列里，具体的数目由fifo_batch来确定。 只有遇到三种情况才会导致一次批量传输的结束 ：1.对应的sort_list中已经没有请求了；2.下一个请求的扇区不满足递增的要求；3.上一个请求已经是批量传输的最后一个请求了。
所有的请求在生成时都会被赋上一个期限值，并且按期限值将它们排序在fifo_list中， 读请求的期限时长默认为500ms，写请求的期限时长默认为5s。 在Deadline调度器定义了一个writes_starved默认值为2，写请求的饥饿线。 内核总是优先处理读请求，当饿死进程的次数超过了writes_starved后，才会去考虑写请求 。 为什么内核会偏袒读请求呢? 这是从整体性能上进行考虑的。读请求和应用程序的关系是同步的，因为应用程序要等待读取完毕，方能进行下一步工作所以读请求会阻塞进程，而写请求则不一样。应用程序发出写请求后，内存的内容何时被写入块设备对程序的影响并不大，所以调度器会优先处理读请求。
3) NOOP
一个简单的FIFO 队列，不执行任何数据排序。NOOP 算法简单地合并相邻的数据请求，所以增加了少量的到磁盘I/O的处理器开销。NOOP电梯调度假设一个块设备拥有它自己的电梯算法。当后台存储设备能重新排序和合并请求，并能更好地了解真实的磁盘布局时，通常选择NOOP调度，
4）Anticipatory
Anticipatory本质上与Deadline一样，但Anticipatory电梯调度在处理最后一个请求之后会等待一段很短的时间，约6ms(可调整antic_expire改变该值)，如果在此期间产生了新的I/O请求，它会在每个6ms中插入新的I/O操作，这样可以将一些小的I/O请求合并成一个大的I/O请求，从而用I/O延时换取最大的I/O吞吐量。
Linux内核使用设备驱动程序得到设备的控制权。 设备驱动程序 通常是一个独立的内核模块，通常针对每个设备(或是设备组)而提供，以便这些设备在Linux操作系统上可用。一旦加载了设备驱动程序，将被当作Linux内核的一部分运行，并能控制设备的运行。
SCSI (Small Computer System Interface，小型计算机系统接口)是最常使用的I/O设备技术，尤其在企业级服务器环境中。SCSI在 Linux 内核中实现，可通过设备驱动模块来控制SCSI设备。 SCSI包括以下模块类型 ：
1) Upper IeveI drivers(上层驱动程序)。 sd_mod、sr_mod（SCSI-CDROM）、st（SCSI Tape）和sq（SCSI通用设备）等。
2) MiddIe IeveI driver(中层驱动程序) 。如scsi_mod实现了 SCSI 协议和通用SCSI功能。
3) Low IeveI drivers(底层驱动程序) 。提供对每个设备的较低级别访问。底层驱动程序基本上是特定于某一个硬件设备的，可提供给某个设备。
4) Pseudo drive(伪驱动程序) 。如ide-scsi，用于 IDE-SCSI仿真。
通常一个较大的性能影响是文件系统元数据怎样在磁盘上存放 。引入 磁盘条带阵列 (RAID 0、RAID 5和RAID 6)解决这个问题。在一个条带阵列上，磁头在移动到阵列中下一个磁盘之前，单个磁盘上写入的数据称为 CHUNKSIZE ，所有磁盘使用一次它后返回到第一个磁盘。 如果文件系统的布局没有匹配RAID的设计，则有可能会发生一个文件系统元数据块被分散到2个磁盘上，导致对2个磁盘发起请求 。或者 将所有的元数据在一个单独的磁盘上存储，如果该磁盘发生故障则可能导致该磁盘变成热点 。
设计RAID阵列需要考虑以下内容：
1) 文件系统使用的块大小。
2) RAID 阵列使用的CHUNK大小。
3) RAID 阵列中同等磁盘的数量。
块大小 指可以读取/写入到驱动器的最小数据量，对服务器的性能有直接的影响。块的大小由文件系统决定，在联机状态下不能更改，只有重新格式化才能修改。可以使用的块大小有1024B、2048B、4096B，默认为 4096 B。
stride条带 是在一个chunk中文件系统块的数量。如果文件系统块大小为4KB，则chunk大小为64KB，那么stride是64KB/4KB=16块。
stripe-width 是RAID阵列上一个条带中文件系统块的数量。比如 一个3块磁盘的RAID5阵列 。按照定义，在RAID5阵列每个条带中有1个磁盘包含奇偶校验内容。想要得到stripe-width，首先需要知道每个条带中有多少磁盘实际携带了数据块，即3磁盘-1校验磁盘=2数据磁盘。2个磁盘中的stride是chunk中文件系统块的数量。因此能计算 2（磁盘）*16（stride）=32（stripe）。
创建文件系统时可以使用mkfs给定数量：mk2fs -t ext4 -b 4096 -E stripe=16,stripe_width=64 /dev/vda