iscsi:IO操作流程（二）

上次我们讨论了iscsi initiator IO操作需要经过的各个层次，以及每层所涉及的IO数据结构的变化。今天主要讨论IO如何形成SCSI指令并下发的。
我们知道在通用块层，IO最终放在request_queue中暂时保存。为了减少寻道时间，通用块层采用“蓄流”的方式，将IO蓄到队列里一段时间，使接下来的IO有机会与已经存在的IO进行合并，即所谓的电梯算法。
当在一定合适的时机，“蓄流”打开时，IO继续进行向下层传递，进而调用块设备驱动为其请求队列提供的request_fn进行处理。SCSI磁盘驱动在扫描发现并为磁盘分配请求队列时将期实例化。具体指向为scsi_request_fn函数。
下图展现了scsi_request_fn的调用情况。

该函数调用blk_peek_request中逐个取出请求，并进行处理。每次调用它就从可处理的请求队列中获到一个请求。请求有可能是新的，有可能是由于SCSI子系统的底层相关设备不能处理请求再次加入到请求队列的。如果已经处理过意味着scsi cmd已经申请；如果是新的，调用prep_rq_fn进行一些请求处理前的准备工作。scsi磁盘驱动（以下简称sd）在这个时间进行SCSI命令的构建（SCSI CDB）。这个预期可能有三种返回值：

- BLKPREP_OK:表示命令初期准备成功，则继续往下执行
- BLKPREP_DEFER:暂时不能够进行处理，则将请求再次加入到队列
- BLKPREP_KILL：请求没办法继续进行下去。这时从队列中请下请求，向上层报告IO失败。

接下来做三件事：

首先，进行设备的检查工作。
当前的计算机体系结构中，设备的操作明显慢于CPU的计算能力，是现代计算机的关键瓶颈之一。因而，在真正需要设备进行处理之前，尽可能的完善检查IO处理的条件是否已经满足。总之，针对IO层面的错误处理，要么尽可能多的恢复现场使业务能够正常的运行下去，要么尽可能的早的失败，给予应用进行错误处理的机会。此次的检查主要针对后者ÿ