Linux SCSI回调IO的分析
本文转载自：http://blog.csdn.net/xushiyan/article/details/6941640，如需参考，请访问原始链接地址。
没找到如何转载的入口，只好全文copy了。
-----------------------------------分割线-------------------------------------------------
LINUX 内核中 SCSI 子系统由 SCSI 上层，中间层和底层驱动模块 [1] 三部分组成，主要负责管理 SCSI 资源和处理其他子系统，如文件系统，提交到 SCSI 子系统中的 IO 请求。因此，理解 SCSI 子系统的 IO 处理机制对理解整个 SCSI 子系统就显的十分重要，同时也有助于理解整个 LINUX 内核的 IO 处理机制。本文从 SCSI 设备访问请求的提交，SCSI 子系统对访问请求的处理和 SCSI 子系统错误处理三个方面，阐述了 SCSI 子系统的 IO 处理机制。
SCSI 设备访问请求的提交分为两个步骤：用户空间提交访问请求到通用块层以及通用块层提交块访问请求到 SCSI 子系统。
在 LINUX 用户空间，有三种方式提交对 SCSI 设备的访问请求到通用块层：
- 通过文件系统提供的文件访问接口进行访问。对建立在 SCSI 设备上的 LINUX 文件系统中的文件读写操作，就属于这种访问方式；
- RAW 设备访问方式。这种访问方式比较常见的应用就是
dd命令。 RAW 设备访问方式和通过文件系统提供的文件访问接口进行访问的最大区别在于前者对 SCSI 设备直接进行线性地址访问，不需要由文件系统进行地址映射； - SCSI PASSTHROUGH 方式。通过 LINUX 提供的 SG 进行访问，就属于这种方式，用户可以直接发 CDB[2] 命令给 SCSI 设备。所以，通过该接口，用户可以做一些 SCSI 管理操作，如 SES 管理等。
图 1 显示了 LINUX 内核对于三种请求提交方式的处理过程。
经由文件系统或 RAW 设备方式提交的请求，会通过底层块设备访问层（ll_rw_block())，由其生成块 IO 请求（BIO），并提交给通用块层 [3] ；而通过 SG 接口提交的访问请求，会调用 SCSI 中间层提供的接口，将请求直接交由通用块层进行处理。
为什么要通过通用块层呢？这是因为首先通用块层会根据磁盘访问的特性对请求进行优化操作；其次，通用块层提供了调度功能，能够对请求进行调度；再次，通用块层可扩展的结构，使各种设备的块驱动都能比较容易的和其集成。
当请求提交到通用块层后，通用块层需要完成准备，调度并交付块访问请求给 SCSI 中间层的操作。块访问请求可以理解为描述了块访问区域，访问方式和关联的 BIO 的请求，在内核中用 ‘struct request‘结构表示。块设备会有对应的块访问请求设备队列，用于记录需要该设备处理的访问请求，新生成的块访问请求会被加入到对应设备的块访问请求队列中。 SCSI 子系统对 IO 的处理，实际上是处理块访问请求队列上的块访问请求。
通用块层提供了两种方式调度处理块访问请求队列：直接调度和通过 LINUX 内核工作队列机制调度执行。两种方式，最后都会调用块访问请求队列处理函数进行处理，而 SCSI 设备在初始化时会向通用块层注册 SCSI 子系统定义的块访问请求队列处理函数。清单 1[4] 显示了这个过程。这样当通用块层处理 SCSI 设备的块访问请求队列时，调用的就是 SCSI 中间层定义的这些处理函数。通过这种方式，通用块层就将块访问请求的处理交给了 SCSI 子系统。
struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)
{ ……
q = blk_init_queue(scsi_request_fn, NULL);
//request generate block layer allocate a request queue
……
blk_queue_prep_rq(q, scsi_prep_fn); //Prepare a scsi request
blk_queue_max_hw_segments(q, shost->sg_tablesize);
//define sg table size
……
blk_queue_softirq_done(q, scsi_softirq_done);
}
当 SCSI 子系统的请求队列处理函数被通用块层调用后，SCSI 中间层会根据块访问请求的内容，生成、初始并提交 SCSI 命令 (struct scsi_cmd) 到 SCSI TARGET 端。
SCSI 命令记录了命令描述块 (CDB)，感测数据缓存 (SENSE BUFFER)，IO 超时时间等 SCSI 相关的信息和 SCSI 子系统处理命令需要的一些其他信息，如回调函数等。清单 2 显示了这个命令的主要结构。
struct scsi_cmnd {
……
void (*done) (struct scsi_cmnd *); /* Mid-level done function */
……
int retries; /*retried time*/
int timeout_per_command; /*timeout define*/
……
enum dma_data_direction sc_data_direction; /*data transfer direction*/
……
unsigned char cmnd[MAX_COMMAND_SIZE]; /*cdb*/
void *request_buffer; /* Actual requested buffer */
struct request *request; /* The command we are working on */
……
unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE];
/* obtained by REQUEST SENSE when
* CHECK CONDITION is received on original
* command (auto-sense) */
/* Low-level done function - can be used by */
/*low-level driver to point to completion function. */
void (*scsi_done) (struct scsi_cmnd *);
……
};
初始化的过程首先按照电梯调度算法，从块设备的请求队列上取出一个块访问请求，根据块访问请求的信息，定义 SCSI 命令中数据传输的方向，长度和地址。其次，定义 CDB，SCSI 中间层的回调函数等。
在完成初始化后，SCSI 中间层通过调用scsi_host_template[5]结构中定义的queuecommand函数将 SCSI 命令提交给 SCSI 底层驱动部分。queuecommand函数，是一个 SCSI 命令队列处理函数，在 SCSI 底层驱动中，定义了queuecommand函数的具体实现。因此，SCSI 中间层，调用queuecommand函数实际上就是调用了底层驱动定义的queuecommand函数的处理实体，将 SCSI 命令提交给了各个厂家定义的 SCSI 底层驱动进行处理。这个过程和通用块设备层调用 SCSI 中间层的处理函数进行块请求处理的机制很相似，这也体现了 LINUX 内核代码具有很好的扩展性。底层驱动接受到请求后，就要开始处理 SCSI 命令了，这一层和硬件关系紧密，所以这块代码一般都是由各个厂家自己实现。基本流程可概括为：从底层驱动维护的队列中，取出一个 SCSI 命令，封装成厂家自定义的请求格式，然后采用 DMA 或者其他方式，将请求提交给 SCSI TARGET 端，由 SCSI TARGET 端对请求处理，并返回执行结果给 SCSI 底层驱动层。
当 SCSI 底层驱动接受到 SCSI TARGET 端返回的命令执行结果后，SCSI 子系统主要通过两次回调过程完成对命令执行结果的处理。 SCSI 底层驱动在接受到 SCSI TARGET 端返回的命令执行结果后，会调用 SCSI 中间层定义的回调函数，将处理结果交付给 SCSI 中间层进行处理，这是第一次回调过程。 SCSI 中间层处理完成后，将调用 SCSI 上层定义的回调函数，结束 IO 在整个 SCSI 子系统中的处理，这为第二次回调过程。
第一次回调：
SCSI 中间层在调用queuecommand函数将 SCSI 命令提交给 SCSI 底层驱动的同时，也将回调函数指针传给了 SCSI 底层驱动。底层驱动接受到 SCSI TARGET 端返回的命令执行结果后，会调用该回调函数，产生一个中断号为 BLOCK_SOFTIRQ 的软中断进行第一次回调处理。在这次回调处理过程中，SCSI 中间层首先会根据 SCSI 底层驱动处理的结果判断请求处理是否成功。处理成功，并不意味着处理没有错误，而是返回的信息，能够让 SCSI 中间层很明确的知道，对于这个命令，中间层已经没有必要继续进行处理了。所以，对于处理成功的 SCSI 命令，SCSI 中间层会调用第二次回调函数进入到第二次回调过程。清单 3 显示了 SCSI 中间层定义的该软中断的处理函数。
static void scsi_softirq_done(struct request *rq)
{
……
disposition = scsi_decide_disposition(cmd);
……
switch (disposition) {
case SUCCESS:
scsi_finish_command(cmd);
//enter to second callback process
break;
case NEEDS_RETRY:
scsi_retry_command(cmd);
break;
case ADD_TO_MLQUEUE:
scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY);
break;
default:
if (!scsi_eh_scmd_add(cmd, 0))
scsi_finish_command(cmd);
}
}
第二次回调：
不同的 SCSI 上层模块会定义自己不同的第二次回调函数，如 SD 模块，会在sd_init_command函数中，定义自己的第二次回调函数sd_rw_intr，这个回调函数会根据 SD 模块的需要，对 SCSI 命令执行的结果做进一步的处理。清单 4 显示了 SD 模块注册第二次回调的代码。虽然各个 SCSI 上层模块可以定义自己的第二次回调函数，但是这些回调函数最终都会结束 SCSI 子系统对这个块访问请求的处理。
static int sd_init_command(struct scsi_cmnd * SCpnt)
{
……
SCpnt->done = sd_rw_intr;
return 1;
}
由于 SCSI 底层驱动是由厂商自己实现的，在此就不予讨论。除此之外，SCSI 子系统的出错处理，主要是由 SCSI 中间层完成。在第一次回调过程中，SCSI 底层驱动将 SCSI 命令的处理结果以及获取的 SCSI 状态信息返回给 SCSI 中间层，SCSI 中间层先对 SCSI 底层驱动返回的 SCSI 命令执行的结果进行判断，若无法得到明确的结论，则对 SCSI 底层驱动返回的 SCSI 状态、感测数据等进行判断。对于判断结论为处理成功的 SCSI 命令，SCSI 中间层会直接进行第二次回调；对于判断结论为需要重试的命令，则会被加入块设备请求对列，重新被处理。这个过程可称为 SCSI 中间层对 SCSI 命令执行结果的基本判断方法。
一切看起来似乎是这么简单，但是实际上并非如此，有些错误是没有明确的判断依据的，如感测数据错误或 TIMEOUT 错误。为了解决这个问题，LINUX 内核中 SCSI 子系统引入了一个专门进行错误处理的线程，对于无法判断错误原因的 SCSI 命令，都会交由该线程进行处理。线程处理过程和两个队列密切相关，一个是错误处理队列（eh_work_q），一个是错误处理完成队列 (done_q) 。错误处理队列记录了需要进行错误处理的 SCSI 命令，错误处理完成队列记录了在错误处理过程中被处理完成的 SCSI 命令。清单 5 显示了线程对错误处理队列上记录的命令进行错误处理的过程。
scsi_unjam_host{
……
if (!scsi_eh_get_sense(&eh_work_q, &eh_done_q))
//get sense data
if (!scsi_eh_abort_cmds(&eh_work_q, &eh_done_q))
//abort command
scsi_eh_ready_devs(shost, &eh_work_q, &eh_done_q);
//reset
scsi_eh_flush_done_q(&eh_done_q);
//complete error io on done_q
……
}
整个处理过程可归纳为四个阶段：
- 感测数据查询阶段
通过查询感测数据，为处理 SCSI 命令重新提供判断依据，并按照前述基本判断方法进行判断。如果判断结果为成功或者重试，则可将该命令从错误处理队列移到错误处理完成队列。若判断失败，则命令将会继续保留在 SCSI 错误处理队列中，错误处理进入到 ABORT 阶段。
- ABORT阶段
在这个阶段中，错误处理队列上的 SCSI 命令会被主动 ABORT 掉。被 ABORT 的命令，会被加入到错误处理完成队列。若 ABORT 过程结束，错误处理队列上还存在未能被处理的命令，则需进入 START STOP UNIT 阶段进行处理。
- START STOP UNIT阶段
在这个阶段，START STOP UNIT[6] 命令会被发送到与错误处理队列上的命令相关的 SCSI DEVICE 上，去试图恢复 SCSI DEVICE，如果在 START STOP UNIT 阶段结束后，依旧有命令在错误处理队列上，则需要进入 RESET 阶段进行处理。
- RESET阶段
RESET 阶段的处理过程分三个层次：DEVICE RESET，BUS RESET 和 HOST RESET 。首先对与错误队列上的命令相关的 SCSI DEVICE，进行 RESET 操作，如果 DEVICE RESET 后，SCSI 设备能处于正常状态，则和该设备相关的错误处理队列上的错误命令，会被加入到错误处理完成队列中。若通过 DEVICE RESET 不能处理所有的错误命令，则需进入到 BUS RESET 阶段，BUS RESET 会对与错误处理队列上的命令相关的 BUS，进行 RESET 操作。若 BUS RESET 还不能成功处理所有错误处理队列上的 SCSI 命令，则会进入到 HOST RESET 阶段，HOST RESET 会对与错误处理队列上的命令相关的 HOST 进行 RESET 操作。当然，很有可能 HOST RESET 也不能成功处理所有错误命令，则只能认为错误处理队列上错误命令相关的 SCSI 设备不能被使用了。这些不能被使用的设备会被标记为不能使用状态，同时相关的错误命令都会被加入到错误处理完成队列中。
对于被加入到错误处理完成队列上的请求，若是在设备状态正确，命令重试次数小于允许次数的情况下，这些命令将被重新加入到块访问请求队列中，进行重新处理；否则，直接进行第二次回调处理，完成 SCSI 子系统对块访问请求的处理。这样，SCSI 子系统就完成了 SCSI 命令错误处理的整个过程。
Scsi Disk设备驱动通过Scsi middle level层向scsi host提交请求，scsi disk driver是一个块设备驱动，其调用块设备层的unplug_fn函数处理scsi disk的请求队列。在处理scsi disk请求队列过程中会调用scsi middle level层注册的scsi_request_fn函数实现具体的操作。Scsi_request_fn函数会从io调度队列中获取一个请求，然后将该请求转换成scsicommand，最后直接调用scsi_dispatch_cmd函数将scsi命令提交给scsi host。Scsi host与scsi middle level层的接口是queue_command函数，每个scsi host驱动都会向scsi middle level层注册具体的queue_command方法。由于Queue_command函数在不可睡眠的上下文中执行，所以其不能处理复杂的操作，通常的操作是将接收到的scsi命令放置到scsi host维护的处理队列中。如果一个真是的scsi host，而不是一个虚拟的host时，那么在scsi host层可以将scsi command通过DMA的方式传输到scsi disk。上述过程完成了一个io请求的提交过程，对于诸如磁盘这样的设备，在这一过程中需要考虑到存储介质的特性以及应用访问模式的特性，所以需要做一些IO调度的策略，使得scsi磁盘的读写更加满足存储介质的特性。当然也可以在scsidisk的上层实现更加高级的IO管理策略。IO请求的提交可以理解为整个IO过程的前半部，那么后半部就是IO完成的回调过程，下文分析Linux中IO回调路径的具体实现。
当一个IO事件完成之后，scsi disk会采用中断的方式通知scsi host驱动。当scsi host的中断事件发生之后，CPU会执行host的中断服务程序，通常实际的scsi host都会以PCI设备的形式存在，考虑到中断共享问题，在中断服务程序中首先需要进行中断事件的判断，然后根据scsihost的状态寄存器进行具体中断任务的处理。对于读写IO请求，当数据DMA到scsi disk之后会产生DMA结束中断信号，在DMA过程中可以采用聚散DMA（scatter-gather DMA）的技术，因此这一过程不会涉及到数据的内存拷贝，也就是说在读写IO过程中，数据一直处于bio的Page页中（写数据过程中会直接将Page页中的数据DMA到磁盘，读数据过程中直接将磁盘中的数据DMA到bio的Page中，这样的处理机制效率较高）。当host确定完成请求之后，会调用scsimiddle level的回调函数，该回调函数就是著名的scsi_done。Scsi_done在queue_command的过程中被提交到scsi host层。在scsi_done函数中直接调用了blk_complete_request函数，该函数通过raise_softirq_irqoff(BLOCK_SOFTIRQ)触发了scsi的软中断。到目前为止，上述过程都在scsi host的中断上半部中执行。中断上半部运行时间不能过长，否则会导致中断事件的丢失。触发软中断之后，中断上半部就可以退出了。在退出上半部之后，CPU将会交给已经触发的scsi软中断服务程序，此时可以看到软中断的服务程序仍然运行在中断上下文，并不是一个可以调度的context。
软中断的执行函数是blk_done_softirq，由于是scsi command引发的中断事件，因此会调用事先注册到请求队列上的scsi_softirq_done函数，完成具体的scsi软中断下半部事件处理。在该函数中会进行一些scsi command执行的正确性判断，如果命令执行错误，那么可以采用重试的方法进行命令的requeue处理，当重试到一定程度之后会将执行错误的scsi命令交给scsi错误处理内核守护进程，进行最后的判决；如果执行成功，那么调用scsi_finish_command函数结束掉scsi命令。在scsi_finish_command函数中调用scsi_io_completion函数结束块级的io request，具体会调用scsi_end_request函数，然后调用blk_end_request函数，最后调到blk_end_io函数。在blk_end_io函数中会结束掉request上的所有bio，结束bio的过程可以调用bio_endio函数。Request中的所有bio都结束之后释放request资源。至此，一个bio所在的request被scsi disk处理完毕之后，通过中断上半部和下半部已经全部处理完毕。这里需要注意的是，IO的所有回调过程都是在中断上下文中处理的，所以在编写IO的回调函数时需要注意睡眠问题，需要考虑内存分配可能带来的睡眠，信号量的使用会导致睡眠，从而使系统崩溃。
通过上述分析，scsi disk的正常IO回调路径涉及的函数描述如下：scsi_doneàblk_done_softirqàscsi_softirq_doneàscsi_finish_commandàscsi_io_completionàscsi_end_requestàblk_end_ioàbio_endio。
最近Linux在Scsi middle level方面变化比较大，上述的分析基于较新的Linux-2.6.28版本，和前面的2.6.18版本相比IO回调流程也发生了一定变化。
本文浅析了 SCSI 子系统中的 IO 处理机制，希望对大家理解 SCSI 子系统和块设备驱动能有所帮助。
- 【 1 】 Linux SCSI 子系统剖析 -http://www.ibm.com/developerworks/cn/linux/l-scsi-subsystem/。
- 【 2 】 请参考 SCSI Primary Commands-4(SPC4)。
- 【 3 】《 Linux 内核分析及编程》，倪继利，电子工业出版社。
- 【 4 】http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.8.tar.gz(GPL LICENCE Version 2)。
- 【 5 】《 Linux 核心》 ,David A Rusling，http://man.ddvip.com/os/linux_kern/drivers.htm。
- 【 6 】参考：“ SCSI-3 BLOCK Commands (SBC) ”，Information Technology Industry Council。
- 在 developerWorks Linux 专区 寻找为 Linux 开发人员（包括 Linux 新手入门）准备的更多参考资料，查阅我们 最受欢迎的文章和教程。
- 在 developerWorks 上查阅所有 Linux 技巧 和 Linux 教程。