一种I/O请求派发方法及装置与流程

本申请涉及计算机
技术领域：
，尤其涉及一种输入/输出(input/output，i/o)请求派发方法及装置。
背景技术：
：大数据时代的数据量呈指数级增长，预计每两年就会翻一番。硬盘(harddiskdrive，hdd)作为一种经济高效的存储介质，在当今的存储数字世界中依然起着中流砥柱的作用。但是，传统硬盘即将达到其存储密度极限，存储业界引入了叠瓦式磁记录(shingledmagneticrecording，smr)盘技术来克服限制提升容量。如图1所示，示意了传统硬盘与smr盘的结构。从图1内容可以看出，smr盘采用叠瓦式记录，通过将一定区域内的磁道依次部分重叠，获得了更高的存储面密度、更大的磁盘容量、更低的单位容量价格。但是，smr盘在带来上述好处的同时，对于上层应用的i/o行为提出了顺序性约束，即只支持顺序写入。smr盘按照固定大小在逻辑上被分割成一个个区域(zone)，一个zone包含了一段连续的逻辑区块地址(logicalblockaddress，lba)。zone分为两类：允许随机写的传统区域(conventionalzone，c-zone)和只支持顺序写的顺序区域(sequentialzone，s-zone))。smr盘读写i/o的顺序性约束体现在一个s-zone内只能进行顺序写，多个s-zone之间则可以进行并发写入。在i/o栈中，i/o调度器管理块设备的请求队列，通过合并i/o请求、对i/o进行排序来于减少磁盘寻道次数，从而提高磁盘性能。i/o调度器在接收到i/o请求时，先将i/o请求添加到i/o调度队列，再按特定的调度算法将调度队列中的i/o请求转移到派发队列，最终提交执行。为支持smr盘s-zone内的顺序写，i/o栈中的各个部分都需要支持保序。为了防止i/o乱序，对smr盘的每一个s-zone引入一个用于写i/o保序的锁，称为zone锁(zonelock)。在写i/o下发时加锁，在写i/o返回时解锁，确保任何时刻对于一个s-zone，最多只有一个写请求被下发到smr盘上，确保smr盘s-zone内不会发生写i/o乱序。因此，i/o调度器对smr盘的调度行为受到zone锁状态的控制，跳过被zone锁阻塞的写i/o请求的方式来对smr盘进行调度，即将写i/o请求下发到smr盘上时，将只允许向未锁定的目标s-zone下发写i/o，如果目标s-zone被锁定了，那么这个写请求将不被派发，放回调度队列，调度器将继续查找下一个能下发的写请求。当smr盘存在多个zone并发顺序写时，若存在写i/o请求被zone锁阻塞，调度器跳过被zone锁阻塞的写i/o请求调度下一个写i/o请求，导致硬盘磁头寻道至另一个zone；在多个写i/o请求被zone锁阻塞的多zone并发顺序写场景下，则会引起磁头的反复摆动，产生寻道风暴,增加大量不必要的随机i/o，引起性能下降。如果zone与zone间隔较远，对smr盘性能影响更加显著。技术实现要素：本申请实施例提供一种i/o请求派发方法及装置，顺序并发调度写i/o请求时避免寻道风暴，提高smr盘的性能。为达到上述目的，本申请的实施例采用如下技术方案：第一方面，提供一种i/o请求派发方法，该方法可以包括：查询写i/o请求在smr盘中的目标zone的zone锁状态；若该zone锁处于锁定状态，监听该zone锁的状态；在监听到该zone锁解锁时，将该写i/o请求派发至该目标zone。本申请提供的i/o请求派发方法，在目标zone的zone锁处于锁定状态时，等待监听其解锁后派发写i/o请求，即使多zone并发顺序写场景下多个写i/o请求被zone锁阻塞，等待解锁后再派发不会引起磁头的反复摆动，避免了寻道风暴，进而保证了smr盘的性能。进一步的，由于smr盘在s-zone内顺序追加的特点，被zone锁阻塞的写i/o请求一般是同一个zone内顺序追加的写i/o,等待解锁后再派发会让i/o请求写入更加顺序化，最小化了磁头的移动距离，优化了寻道时间，提高了对smr盘的i/o访问性能。其中，上述写i/o请求为调度队列中顺序最优先的待派发的写i/o请求。调度队列中按序存储了至少一个i/o请求，调度队列中i/o请求的顺序可以根据各种调度算法排列，本申请对此不进行具体限定。结合第一方面，在一种可能的实现方式中，在监听到zone锁解锁时，将写i/o请求派发至目标zone，具体可以实现为：在预设时长内监听到zone锁解锁时，将写i/o请求派发至目标zone。相应的，本申请提供的i/o请求派发方法还可以包括：若在预设时长内zone锁一直锁定，跳过该写i/o请求派发其他i/o请求。在该实现方式中，通过预设时长限定最长等待时间，避免过长时间等待。跳过写i/o请求后，处理下一个待派发的i/o请求，其具体过程相同，此处不再进行赘述。结合第一方面或上述任一方面可能的实现方式，在另一种可能的实现方式中，在查询写i/o请求在smr盘中的目标zone的zone锁状态之后，本申请提供的i/o请求派发方法还可以包括：若该zone锁处于解锁状态，将写i/o请求派发至目标zone。结合第一方面或上述任一方面可能的实现方式，在另一种可能的实现方式中，在将写i/o请求派发至目标zone后，本申请提供的i/o请求派发方法还可以包括：锁定目标zone的zone锁。以实现采用zone锁对i/o请求派发过程的保序。第二方面，提供一种i/o请求派发装置，该装置可以包括查询单元、监听单元以及派发单元。其中，查询单元，用于查询写i/o请求在smr盘中的目标zone的zone锁状态；监听单元，用于若查询单元查询zone锁处于锁定状态，监听zone锁的状态；派发单元，用于在监听单元监听到zone锁解锁时，将写i/o请求派发至目标zone。本申请提供的i/o请求派发装置，在目标zone的zone锁处于锁定状态时，等待监听其解锁后派发写i/o请求，即使多zone并发顺序写场景下多个写i/o请求被zone锁阻塞，等待解锁后再派发不会引起磁头的反复摆动，避免了寻道风暴，进而保证了smr盘的性能。进一步的，由于smr盘在s-zone内顺序追加的特点，被zone锁阻塞的写i/o请求一般是同一个zone内顺序追加的写i/o,等待解锁后再派发会让i/o请求写入更加顺序化，最小化了磁头的移动距离，优化了寻道时间，提高了对smr盘的i/o访问性能。结合第二方面，在一种可能的实现方式中，派发单元具体可以用于：在监听单元在预设时长内监听到zone锁解锁时，将写i/o请求派发至目标zone。若在预设时长内zone锁一直锁定，跳过写i/o请求派发其他i/o请求。跳过写i/o请求后，处理下一个待派发的i/o请求，其具体过程相同，此处不再进行赘述。结合第二方面或上述任一种可能的实现方式，在另一种可能的实现方式中，派发单元还可以用于：若查询单元查询zone锁处于解锁状态，将写i/o请求派发至目标zone。结合第二方面或上述任一种可能的实现方式，在另一种可能的实现方式中，该装置还可以包括：锁定单元，用于在派发单元将写i/o请求派发至目标zone后，锁定目标zone的zone锁。需要说明的是，第二方面提供的i/o请求派发装置，用于实现上述第一方面或任一种可能的实现方式提供的i/o请求派发方法，其具体实现可以参考第一方面或第一方面的任一种可能的实现方式，此处不再一一赘述。第三方面，本申请提供一种i/o请求派发装置，该i/o请求派发装置可以实现上述方法示例中的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。结合第三方面，在一种可能的实现方式中，该i/o请求派发装置的结构中包括处理器和收发器，该处理器被配置为支持该i/o请求派发装置执行上述方法中相应的功能。该收发器用于支持该i/o请求派发装置与其他设备之间的通信。该i/o请求派发装置还可以包括存储器，该存储器用于与处理器耦合，其保存该i/o请求派发装置必要的程序指令和数据。需要说明的是，第三方面提供的i/o请求派发装置，用于实现上述第一方面或任一种可能的实现方式提供的i/o请求派发方法，其具体实现可以参考第一方面或第一方面的任一种可能的实现方式，此处不再一一赘述。第四方面，提供一种i/o调度器，包括如上述第三方面提供的i/o请求派发装置。第五方面，本申请实施例提供了一种计算机存储介质，包括指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任一种可能的实现方式所设计的程序。第六方面，本申请实施例提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第一方任一种可能的实现方式所设计的程序。上述第四方面至第六方面提供的方案，用于实现上述第一方面提供的i/o请求派发装置，因此可以与第一方面达到相同的有益效果，此处不再进行赘述。附图说明图1为传统硬盘与smr盘的结构示意图；图2为smr盘zone的划分以及wp指示的示意图；图3为现有技术提供的基于smr盘的系统i/o栈架构示意图；图4为现有技术提供的一种i/o调度器的内部结构示意图；图5为现有技术提供的一种最后期限调度算法中i/o调度器的内部结构示意图；图6为一种smr盘zone锁与i/o调度器的交互场景示意图；图7为现有技术中提供的一种i/o请求派发方法的流程示意图；图8为现有技术提供的一种调度队列中i/o请求的派发顺序示意图；图8a为一种i/o调度器的架构示意图；图9为linux通用块层中i/o请求的处理过程的流程示意图；图10为i/o调度器工作的总体流程的示意图；图11为本申请实施例提供的一种i/o请求派发装置的结构示意图；图12为本申请实施例提供的一种i/o请求派发方法的流程示意图；图13为本申请实施例提供的另一种i/o请求派发方法的流程示意图；图14为本申请实施例提供的再一种i/o请求派发方法的流程示意图；图15为本申请实施例提供的一种调度队列中i/o请求的派发顺序示意图；图16为本申请实施例提供的另一种i/o请求派发装置的结构示意图；图17为本申请实施例提供的再一种i/o请求派发装置的结构示意图；图18为本申请实施例提供的又一种i/o请求派发装置的结构示意图。具体实施方式smr盘主要应用在视频、归档、备份的场合，这些应用通常具有大文件、顺序写为主的特点。多zone并发顺序写在smr盘上是非常常见的场景。例如，视频监控场景中，多个摄像头录下的多路视频流通过文件系统写入到不同的zone内；数据重构时为提升恢复速度，来自多块备份盘的数据并发地恢复写入到多个zone等。smr盘对写入的顺序性约束可在硬件侧由硬盘本身来管理，亦可在主机侧由软件来进行。前者被称为“驱动器自管理的smr盘”(drivemanagedsmrdisk)，后者被称为主机管理的smr盘(hostmanagedsmr，hmsmr盘)。hmsmr盘向上提供了新接口，不允许上层软件随机写，只允许上层进行顺序追加写，不符合smr盘写入规则的i/o将会报错。如前所述，smr盘按照固定大小(例如256mb)在逻辑上被分割成一个个zone，一个zone包含了一段连续的lba地址。c-zone允许随机写，s-zone只支持顺序写。每个s-zone有一个写指针(writepointer，wp)，wp定位了下一个顺序写可以发生的位置。smr盘只能对wp所在位置的lba进行写入操作，写入其他lba则会报错。从wp位置开始的写操作将自动向后移动写指针。hmsmr盘可以使用reportzones命令获取有关zone和wp的信息。图2示意了smr盘zone的划分以及wp指示。图3展示了基于smr盘的系统i/o栈架构图。如图3所示，在i/o栈中，包括文件系统、配置了i/o调度器的通用块层、小型计算机系统接口(smallcomputersysteminterface，scsi)子系统、主机总线适配器(hostbusadapter，hba)驱动、smr盘。i/o调度器(i/oscheduler)是通用块层的一个重要组成部分。文件系统生成的块i/o(blocki/o)进入通用块层后，在派发给底层smr盘之前，会经过i/o调度器的调度。i/o调度器管理块设备的队列，通过调整队列中的请求排列顺序，对smr盘的i/o性能有着极大的影响。在i/o栈中，i/o调度器(i/oscheduler)是一个重要组成部分，它管理块设备的i/o请求队列，在接收到文件系统提交的i/o请求时，通过合并i/o请求、对i/o进行排序，调整队列中的请求排列顺序，决定在什么时刻派发请求到块设备，以减少磁盘寻道次数，从而提高磁盘性能。i/o调度器从文件系统接收到i/o请求时，生成调度队列，按照调度算法生成派发队列。其中，合并是指将两个或多个i/o请求结合成一个新请求。当文件系统提交i/o请求到请求队列，如果此时队列中己经存在一个请求，它访问的磁盘扇区和当前请求访问的磁盘扇区相邻，那么这两个请求可以合并为一个对两个相邻磁盘扇区操作的新请求。合并请求显然能减少系统开销和磁盘寻址次数。排序则是将进入请求队列的所有i/o请求按扇区编号(lba地址)递增方向有序排列，使得磁头可以按照磁盘的旋转顺序的完成i/o操作，减小磁盘的寻道次数。调度器的算法和电梯运行的策略相似，因此i/o调度器也被称作i/o电梯(i/oelevator)。图4为一种i/o调度器的内部结构示意图。如图4所示，引入i/o调度器后，请求队列就分为两种队列：一种为i/o调度队列，它蕴涵于i/o调度器中；另一种是派发队列(dispatchqueue)，即将派送至入磁盘的i/o请求队列。文件系统提交的i/o请求首先被添加到调度队列，然后，i/o调度器按特定的调度算法将它转移到派发队列，最终被提交执行。在各类针对磁盘的i/o调度器中，根据请求磁盘扇区(lba地址)的顺序在请求队列中进行排序的电梯算法都是其中重要的基础部分。电梯算法着重使i/o的吞吐最大化，各种调度器在其基础上，加入了读写优先级(priority)、i/o公平性(fairness)、避免i/o饿死(starvation)等其他因素方面的考虑，进一步调整i/o请求的顺序，形成了各自的特点和适用场景。这里描述一种基于电梯算法的调度算法的最后期限调度算法。最后期限调度算法一方面以i/o请求的目的区域的扇区编号为次序来维护请求，组成排序队列(sortedqueue)，另一方面也按请求到达的时间为次序来维护请求，组成先进先出(firstinputfirstoutput，fifo)队列，用于先来先服务。图5示意了最后期限调度算法中i/o调度器的内部结构。如图5所示，最后期限调度算法实际使用四个队列，以请求类型为依据区分。也就是说，写操作有一个排序队列和fifo队列，读操作也有一个排序队列和fifo队列。在最后期限调度器中，每个请求都有一个超时时间。默认情况下，读请求的超时时间是500毫秒，写请求的超时时间是5秒，读请求的优先级高于写请求。当新请求被提交，最后期限调度器将其加入到排序队列中进行合并和排序，同时将这个请求加入到fifo队列中，读请求被加入至读fifo队列，写请求被加入到写fifo队列，这两个队列中，请求完全按照fifo顺序排列，即新请求永远被放入到队列的末尾。一般情况下，请求从排序队列中取下，再推入到派发队列；如果写fifo队列或读fifo队列头部有请求超时(也就是，当前时间超过了请求指定的超时时间)，那么最后期限i/o调度器就不再使用排序队列，而是从fifo队列中取出请求放入派发队列，直到队列中没有超时的请求。依靠这种方法，最后期限i/o调度器保证所有的请求都不会长时间超时。因此，最后期限调度器防止了请求饿死(starvation)的出现。需要说明的是，调度算法的类型多种多样，上述描述了最后期限调度算法；但是，本申请可以应用于各种调度算法的场景中，本申请对于调度算法的类型不进行具体限定。如前所述，为支持smr盘s-zone内的顺序写，i/o栈中的各个部分都需要支持保序，通过加zone锁保护的方式实现。在smr盘上，i/o调度器在zone锁的以上，其行为受到zone锁状态的控制。图6示意了smr盘zone锁与i/o调度器的交互场景，如图6所示，调度队列中的wi表示目的地为zonei的写i/o请求，ri表示目的地为zonei的读i/o请求。smr盘上zone0、zone1上分别有一个写i/o正在进行中，因此zone0和zone1上的zone锁处于锁定状态；zone2上有一个读i/o正在进行中，zonen上则没有i/o，zone2和zonen处于未锁定状态。在i/o调度器的调度队列中，第1个写i/o请求的标志为w0，对应的zone0处于上锁状态，因此无法继续往下派发。第4个写i/o请求的标志位w2，对应的zone0处于解锁状态，因此可以往下层驱动派发。具体而言，对于处于一个调度批次的i/o调度队列，当一个写i/o请求被zone锁阻塞，当前的处理方案是跳过被zone锁阻塞的写i/o请求，将该被阻塞的写i/o请求放回调度队列处理下一个待派发i/o请求的方式来对smr盘进行调度。针对smr盘，根据调度器的算法挑选出待派发的候选i/o请求后(加入派发队列前)，现有技术的调度器根据以下原则实现了相应的调度策略：1)任何非写入请求始终允许向下派发；2)任何对c-zone的写入都允许向下派发；3)对于对s-zone的写入,首先检查zone锁。如果该zone未锁定,则允许在锁定目标zone后继续写入操作；如果该zone已锁定,则会跳过写入请求,并尝试调度队列中的下一个请求。也就是说，现有技术中将写i/o请求下发到smr盘上时，将只允许向未锁定的目标s-zone下发写i/o；如果目标s-zone被锁定了，那么这个写请求将不被派发，放回调度队列，调度器将继续查找下一个能下发的写请求。如果在属于同一调度批次的写i/o调度队列内找不到能下发的写请求，那么允许读请求被下发，即使这时候这个写请求所在的写调度批次还没处理完。现有技术中提供的i/o请求派发方法的具体流程示意如图7所示，该流程可以包括如下步骤：s701、i/o调度器判断调度队列是否为空。在s701中，若是，则结束派发流程；否则，执行s702和s703。s702、i/o调度器挑选出待派发的i/o请求。其中，待派发的i/o请求即调度队列中顺序最靠前的i/o请求。s703、i/o调度器判断待派发的i/o请求是否为写请求。在s703中，若是，则执行s704；否则，执行s708向下派发后执行s701。s704、i/o调度器判断待派发的i/o请求的目标区域是否为s-zone。在s704中，若是，则执行s705；否则，执行s708向下派发后执行s701。s705、i/o调度器判断待派发的i/o请求的目标区域的zone锁是否锁定。在s705中，若是，则执行s706后执行s701；否则，执行s707后执行s708向下派发后再执行s701。s706、i/o调度器跳过该待派发的i/o请求，尝试处理调度队列中下一个i/o请求。s707、i/o调度器锁定该待派发的i/o请求的目标区域。s708、i/o调度器向下派发该待派发的i/o请求。图8示意了一个调度队列中i/o请求的派发顺序。如图8所示，在一个写调度批次内，调度队列中共有19个写i/o请求等待调度，矩形中的数字代表现有技术的调度器的方案中写i/o请求的派发顺序。当写i/o被zone锁阻塞时，现有技术的调度器在多zone并发写时会造成磁头不断跳动，在下发zone1的一个写i/o后立即寻道至zone2，下发另一个写i/o，再跳到下一个zone。如果zone与zone之间的间隔较远的话，其性能影响更加显著。因此，当smr盘存在多个zone并发顺序写时，若存在写i/o请求被zone锁阻塞，调度器跳过被zone锁阻塞的写i/o请求调度下一个写i/o请求，导致硬盘磁头寻道至另一个zone；在多个写i/o请求被zone锁阻塞的多zone并发顺序写场景下，则会引起磁头的反复摆动，产生寻道风暴,增加大量不必要的随机i/o，引起性能下降。如果zone与zone间隔较远，对smr盘性能影响更加显著。基于此，本申请提出一种i/o请求派送方法，其基本原理是：当写i/o请求被zone锁阻塞时，等待解锁后派送，避免寻道风暴，提高性能。本申请提供的i/o请求派送方法，应用于如图3所示的smr盘的系统i/o栈架构中。具体的，应用于图3示意的smr盘的系统i/o栈架构中i/o调度器向smr盘派发i/o请求的过程中。基于如图3所示的smr盘的系统i/o栈架构，图8a示意了本申请提供的方案涉及的i/o调度器的架构。如图8a所示，本申请提供的方案涉及的i/o调度器的架构由若干组调度队列、派发队列、zone锁表，以及电梯对象组成。其中，调度队列是i/o调度器维护的一系列队列，这些队列用于对请求的排序，或者执行i/o合并；派发队列用于暂存下发给磁盘驱动的i/o请求，smr盘依次处理派发队列中的i/o；电梯对象是i/o调度器的核心部分，负责从调度队列中依照一定的规则挑选出适当的i/o请求，插入到派发队列的尾部；zone锁表则是smr盘i/o调度器特有的组件，写i/o下发时上锁，写i/o完成时解锁，用于确保同一时刻每个s-zone内最多只有一个写i/o正在执行。需要说明的是，zone锁表可以配置在i/o调度器内部，也可以配置在图3所示的smr盘的系统i/o栈架构中的其他位置，本申请实施例对此不进行具体限定，图8a只是示意并不构成具体限定。在详细介绍本申请提供的i/o请求派送方法之前，为了便于理解，此处先描述linux通用块层中，i/o请求的处理过程。linux通用块层中，i/o请求的处理过程如图9所示，该过程可以包括：s901、上层向块i/o子系统提交通用块层请求(bio)。块i/o子系统向上层提供接收通用块层请求(bio)的接口，上层(文件系统等)在构造好bio后，提交给通用块层处理。s902、从bio构造i/o请求队列(requestqueue)，进行合并与排序。在s902中，经过合并与排序，从bio构造请求队列(requestqueue)。合并将对磁盘连续扇区访问的多个i/o合并为一个i/o，排序是讲i/o按照对磁盘访问的扇区编号进行排序，尽量使磁头向一个方向移动。s903、下层(scsi子系统)逐个处理scsi块设备请求队列(requestqueue)中的请求。在s903中，块i/o子系统将请求队列(requestqueue)中的i/o请求派发到下层scsi子系统中。在图9示意的i/o请求的处理过程中，i/o调度器在s902及s903中发挥着重要作用。下面描述i/o调度器工作的总体流程。如图10所示，i/o调度器工作的总体流程具体可以包括：s1001、调度器为请求队列(requestqueue)建立关联的i/o调度队列。在确定好电梯对象后，为scsi块设备请求队列(requestqueue)分配建立相关联的i/o调度队列。s1002、调度器判断bio是否可以被合并到请求中。在s1002中，接收到bio后，调度器尝试从requestqueue中选择一个可以合并这个bio的request，进行向后合并、向前合并。s1003、调度器将合并后的请求添加到i/o调度队列并排序。准备好request后，块层将其添加到i/o调度队列中，同时按电梯对象要求进行排序，保持i/o调度队列的有序性。s1004、调度器从i/o调度队列派发请求到派发队列。具体的，本申请提供的方案可以应用于s1004的过程中，下面详细描述本申请提供的方案。本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一指示信息和第二指示信息等是用于区别不同的指示信息，而不是用于描述信息的特定顺序。在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。下面结合附图，对本申请的实施例进行具体阐述。一方面，本申请实施例提供一种i/o请求派发装置。i/o请求派发装置可以配置在调度器中，因此，i/o请求派发装置可以为调度器中执行本申请提供的i/o请求派发方法的功能单元。当然，也可以将调度器称之为i/o请求派发装置，本申请实施例对此不进行具体限定。图11示出的是与本申请各实施例相关的一种i/o请求派发装置110。i/o请求派发装置110可以为图3所示的架构中的调度器的部分或全部。如图11所示，i/o请求派发装置110可以包括：处理器1101、存储器1102、收发器1103。下面结合图11对i/o请求派发装置110的各个构成部件进行具体的介绍：存储器1102，可以是易失性存储器(volatilememory)，例如随机存取存储器(random-accessmemory，ram)；或者非易失性存储器(non-volatilememory)，例如只读存储器(read-onlymemory，rom)，快闪存储器(flashmemory)，硬盘(harddiskdrive，hdd)或固态硬盘(solid-statedrive，ssd)；或者上述种类的存储器的组合，用于存储可实现本申请方法的程序代码、以及配置文件。处理器1101是i/o请求派发装置110的控制中心，可以是一个中央处理器(centralprocessingunit，cpu)，也可以是特定集成电路(applicationspecificintegratedcircuit，asic)，或者是被配置成实施本申请实施例的一个或多个集成电路，例如：一个或多个微处理器(digitalsingnalprocessor，dsp)，或，一个或者多个现场可编程门阵列(fieldprogrammablegatearray，fpga)。处理器1101可以通过运行或执行存储在存储器1102内的软件程序和/或模块，以及调用存储在存储器1102内的数据，执行i/o请求派发装置110的各种功能。收发器1103用于i/o请求派发装置110与其他单元进行交互。示例性的，收发器1103可以为i/o请求派发装置110的收发端口。具体的，处理器1101通过运行或执行存储在存储器1102内的软件程序和/或模块，以及调用存储在存储器1102内的数据，执行如下功能：查询写i/o请求在smr盘中的目标区域zone的zone锁状态；若zone锁处于锁定状态，监听zone锁的状态；在监听到zone锁解锁时，将写i/o请求派发至目标zone。另一方面，本申请实施例提供一种i/o请求派发方法，应用于smr盘的系统i/o栈向smr盘派送写i/o请求的过程中。本申请实施例描述的i/o请求派发方法的过程，由i/o请求派发装置执行，i/o请求派发装置可以部署在调度器中作为功能单元或者芯片。文中描述的i/o请求派发装置执行某操作，对此可以理解为由i/o请求派发装置自身执行，也可以理解为由i/o请求派发装置所属的调度器执行，本申请实施例对此不进行具体限定，下文中仅描述为调度器执行某操作。如图12所示，本申请实施例提供的i/o请求派发方法可以包括：s1201、i/o请求派发装置查询写i/o请求在smr盘中的目标zone的zone锁状态。其中，该写i/o请求是调度队列中顺序最优先的待派发的写i/o请求。写i/o请求中携带了该写i/o请求访问的目标zone的标识，如前所述，调度队列是i/o请求派发装置所在的调度器，从文件系统接收i/o请求后配置请求队列后通过合并、排序等方式生成的。本申请实施例对于i/o调度器生成调度队列时的具体过程不进行限定。在生产调度队列后，i/o调度器使用调度算法将调度队列中的i/o请求发送到派送队列中，smr盘依次执行派送队列中的i/o请求，本申请实施例对于i/o调度器所使用的调度算法不进行具体限定。具体的，zone锁表中存储了smr盘中每个zone的zone锁状态，当对某个zone派发写i/o请求进行写入操作，其对应的zone锁则上锁，进入锁定状态，当写入操作结束接收到smr盘反馈的i/o请求完成响应后，其对应的zone锁解锁。写i/o请求中携带了该写i/o请求访问的目标zone的标识，根据该标识查询zone锁表，以查询写i/o请求在smr盘中的目标zone的zone锁状态。其中，zone的标识是唯一识别smr盘中zone的信息，凡是可以用来唯一识别zone的信息，均可以作为zone的标识。例如，该标识可以为字符串、数字等，本申请实施例对于zone的标识的内容不进行具体限定。示例性的，如表1所示，示意了一种zone锁表。表1zone标识zone锁状态1锁定2解锁3解锁4解锁…………需要说明的是，表1只是对zone锁表的示例说明，并不构成对zone锁表的形式以及内容的具体限定。在实际应用中，可以根据需求配置zone锁表的形式以及具体内容，本申请实施例对此不进行具体限定。可选的，zone锁表可以配置在调度器内部，当然，zone锁表也可以配置在smr盘的系统i/o栈中通用块层的其他位置，本申请实施例对此不进行具体限定。具体的，可以为图11示意的i/o请求派发装置110中的处理器1101执行s1201的过程。在执行s1201之后，若查询的该写i/o请求的目标zone的zone锁处于锁定状态，则执行s1202。s1202、若zone锁处于锁定状态，i/o请求派发装置监听该zone锁的状态。具体的，在s1202中，监听该zone锁的状态即实时查询zone锁表，查询其状态。s1203、在监听到该zone锁解锁时，i/o请求派发装置将该写i/o请求派发至目标zone。具体的，当在s1202的监听过程中，监听到该zone锁解锁时，说明该zone已经结束写入操作，当前等待的写i/o请求可以向目标区域派发进行写入操作。示例性的，派发过程可以参考图3示意的smr盘的系统i/o栈架构示意，i/o调度器将派发的i/o请求发送至scsi子系统，再经过hba驱动派发到smr盘中。当然，派发也可以有其他实现方式，本申请实施例对于派发过程不再进行赘述。一种可能的实现中，i/o请求派发装置一直监听该zone锁的状态，直到监听到该zone锁解锁时执行s1203，将该写i/o请求派发至目标zone。另一种可能的实现中，i/o请求派发装置监听该zone锁的状态，并在预设时长内监控到该zone锁解锁时将该写i/o请求派发至目标zone。对应的，s1203则具体实现为：在预设时长内监听到该zone锁解锁时，i/o请求派发装置将该写i/o请求派发至目标zone。可选的，预设时长的长短可以根据实际需求配置，本申请实施例对此不进行具体限定。进一步可选的，若s1203则具体实现为在预设时长内监听到该zone锁解锁时，i/o请求派发装置将该写i/o请求派发至目标zone，本申请实施例提供的i/o请求派发方法还可以包括：若在预设时长内zone锁一直锁定，i/o请求派发装置跳过该写i/o请求，派发其他i/o请求。需要说明的是，s1201至s1203的i/o请求派发方法是针对一个写i/o请求的派发过程，在实际应用中，i/o请求派发装置对于每一个写i/o请求均可以执行s1201至s1203的过程，并且执行过程相同，此处不再一一赘述。本申请提供的i/o请求派发方法，在目标zone的zone锁处于锁定状态时，等待监听其解锁后派发写i/o请求，即使多zone并发顺序写场景下多个写i/o请求被zone锁阻塞，等待解锁后再派发不会引起磁头的反复摆动，避免了寻道风暴，进而保证了smr盘的性能。进一步的，由于smr盘在s-zone内顺序追加的特点，被zone锁阻塞的写i/o请求一般是同一个zone内顺序追加的写i/o,等待解锁后再派发会让i/o请求写入更加顺序化，最小化了磁头的移动距离，优化了寻道时间，提高了对smr盘的i/o访问性能。进一步可选的，如图13所示，在s1201中i/o请求派发装置查询写i/o请求在smr盘中的目标区域zone的zone锁状态之后，本申请实施例提供的i/o请求派发方法还可以包括s1204。s1204、若zone锁处于解锁状态，i/o请求派发装置将写i/o请求派发至目标zone。具体的，当查询到该zone锁解锁时，说明该zone没有写入操作，当前等待的写i/o请求可以直接向目标区域派发进行写入操作。进一步的，如图13所示，在向目标区域派发进行写入操作之后，为了保序，本申请实施例提供的i/o请求派发方法还可以包括s1205。s1205、i/o请求派发装置锁定目标zone的zone锁。需要说明的是，图12及图13示意的本申请实施例提供的i/o请求派发方法，是i/o请求派发装置对调度队列中一个写i/o请求的处理过程，i/o请求派发装置对于调度队列中每个写i/o请求的处理过程相同，此处不再一一赘述。进一步的，在实际应用中，调度队列中还可以包括读i/o请求，以及目标zone为c-zone的i/o请求，因此，在实际应用中，还可以在s1201之前包括其他步骤以实现所有i/o请求的派发。如图14所示，本申请提供的i/o请求派发方法在图12或图13基础上还可以包括其他步骤。其中，图14示意的i/o请求派发方法中包括的其他步骤可以为i/o请求派发装置执行，也可以为i/o请求派发装置所在的i/o调度器执行，本申请实施例对此不进行具体限定，此处仅描述为i/o请求派发装置所在的调度器执行(图14以及相关说明简写为i/o调度器执行)。s1401、i/o调度器判断调度队列是否为空。在s1401中，若是，则结束派发流程；否则，执行s1402和s1403。s1402、i/o调度器挑选出待派发的i/o请求。s1403、i/o调度器判断待派发的i/o请求是否为写请求。在s1403中，若是，则执行s1404；否则，执行s1408向下派发。s1404、i/o调度器判断待派发的i/o请求的目标区域是否为s-zone。在s1404中，若是，则执行s1405；否则，执行s1408向下派发。s1405、i/o调度器判断待派发的i/o请求的目标区域的zone锁是否锁定。在s1405中，若是，则执行s1406；否则，执行s1407向下派发。s1406、i/o调度器监听该zone锁的状态。可选的，在s1406中，在监听到该zone锁解锁时，或者，在预设时长内监听到该zone锁解锁时，i/o调度器执行s1407后执行s1401。可选的，在s1406中，若监听到该zone锁一直锁定或者在预设时长内一直锁定，i/o调度器跳过该写i/o请求执行s1401尝试下一个待派发i/o请求。s1407、i/o调度器将写i/o请求派发至目标区域并锁定目标区域的zone锁。在s1407后，执行s1401以处理下一个i/o请求。s1408、i/o调度器向下派发该待派发的i/o请求。在s1408后，执行s1401以处理下一个i/o请求。示例性的，图8示意的调度队列中i/o请求的派发顺序若采用本申请提供的i/o请求派发方法，其派发顺序则如图15所示，矩形中的数字代表现有技术的调度器的方案中写i/o请求的派发顺序。上述主要从部署了本申请提供的i/o请求派发装置的i/o调度器工作过程的角度对本申请实施例提供的方案进行了介绍。可以理解的是，i/o调度器装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。需要说明的是，i/o调度器中执行本申请提供的i/o请求派发方法的功能部分称之为i/o请求派发装置，可以理解的是，i/o请求派发装置可以为i/o调度器的部分或全部，换言之，i/o请求派发装置可以与i/o调度器等价，或者，i/o请求派发装置也可以部署在i/o调度器内，以支持i/o调度器执行本申请提供的i/o请求派发方法。本申请实施例可以根据上述方法示例对i/o调度器进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。当i/o请求派发装置为i/o调度器的部分或全部时，对i/o调度器进行功能模块的划分，就相当于对i/o请求派发装置进行功能模块的划分；或者，当i/o请求派发装置为i/o调度器的部分或全部时，对i/o请求派发装置进行功能模块的划分，就相当于对i/o调度器进行功能模块的划分。在采用对应各个功能划分各个功能模块的情况下，图16示出了上述实施例中所涉及的i/o调度器中的i/o请求派发装置的一种可能的结构示意图。i/o请求派发装置160可以包括：查询单元1601，监听单元1602，派发单元1603。查询单元1601用于执行图12或图13中的过程s1201；监听单元1602用于执行图12或图13中的过程s1202；派发单元1603用于执行图12或图13中的过程s1203、s1204。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。进一步的，如图17所示，i/o请求派发装置160还可以包括锁定单元1604。锁定单元1604用于执行图13中的过程s1205。在采用集成的单元的情况下，图18示出了上述实施例中所涉及的i/o调度器中的i/o请求派发装置的一种可能的结构示意图。i/o请求派发装置180可以包括：处理模块1801、通信模块1802。处理模块1801用于对i/o请求派发装置180的动作进行控制管理。例如，处理模块1801用于支持i/o请求派发装置180通过通信模块1802支持i/o请求派发装置180执行图12或图13中的过程s1201至s1205。i/o请求派发装置180还可以包括存储模块1803，用于存储i/o请求派发装置180的程序代码和数据。其中，处理模块1801可以为图11所示的i/o请求派发装置110的实体结构中的处理器1101，可以是处理器或控制器。例如可以是cpu，通用处理器，dsp，asic，fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器1801也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等等。通信模块1802可以为图11所示的i/o请求派发装置110的实体结构中的收发器1103，通信模块1802可以是通信端口，或者可以是收发器、收发电路或通信接口等。或者，上述通信接口可以通过上述具有收发功能的元件，实现与其他设备的通信。上述具有收发功能的元件可以由天线和/或射频装置实现。存储模块1803可以是图11所示的i/o请求派发装置110的实体结构中的存储器1102。当处理模块1801为处理器，通信模块1802为收发器，存储模块1803为存储器时，本申请实施例图18所涉及的i/o请求派发装置可以为图11所示的i/o请求派发装置110。如前述，本申请实施例提供的i/o请求派发装置160或i/o请求派发装置180可以用于实施上述本申请各实施例实现的方法中i/o调度器的功能，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请各实施例。另一方面，本申请实施例还提供一种i/o调度器，包括上述任一实施例提供的i/o请求派发装置，具体技术细节请参照本申请各实施例。结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于ram、闪存、rom、可擦除可编程只读存储器(erasableprogrammablerom，eprom)、电可擦可编程只读存储器(electricallyeprom，eeprom)、寄存器、硬盘、移动硬盘、只读光盘(cd-rom)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。另外，该asic可以位于核心网接口设备中。当然，处理器和存储介质也可以作为分立组件存在于核心网接口设备中。或者，存储器可以与处理器耦合，例如存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。存储器可以用于存储执行本申请实施例提供的技术方案的应用程序代码，并由处理器来控制执行。处理器用于执行存储器中存储的应用程序代码，从而实现本申请实施例提供的技术方案。本申请实施例再提供一种芯片系统，该芯片系统包括处理器，用于实现本发明实施例通信设备的技术方法。在一种可能的设计中，该芯片系统还包括存储器，用于保存本发明实施例通信设备必要的程序指令和/或数据。在一种可能的设计中，该芯片系统还包括存储器，用于处理器调用存储器中存储的应用程序代码。该芯片系统，可以由一个或多个芯片构成，也可以包含芯片和其他分立器件，本申请实施例对此不作具体限定。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。当前第1页12