I/O barrier请求用来保证I/O请求的顺序。其主要是针对那些需要保证顺序的写请求，比如日志的checkpoint。在请求队列中，那些排在barrier请求前的请求，必须在barrier请求开始之前完成。(这里所说的完成指数据写入物理介质，而不是保存在OS或者设备缓存中)。而那些排在barrier请求后的请求，只有在barrier请求完成后才能开始(这儿所说的完成，同样是指barrier请求的捎带数据写入物理介质)。

总的来说， I/O barrier请求拥有一下两个性质：

1.请求顺序

非barrier请求不能跨越barrier请求。barrier请求之前的请求必须先于barrier请求进行处理，barrier请求之后的请求必须在barrier请求完成后进行处理。

根据磁盘驱动器的特性，以上条件可以用以下三种方式来实现：

i.对于设备队列深度大于1(TCQ设备)并且支持ordered

tag的设备，块设备层只需要发送一个标为ordered的请求来作为barrier，底层驱动，控制器和磁盘驱动器负责确保请求的顺序。现在，大多数SCSI控制器/磁盘驱动器都应该支持这个特性。

ii. 对于设备队列深度大于1但是不支持ordered

tag的设备，块设备层确保barrier请求往设备分发前，之前的请求将先被处理完。块设备层也会延迟barrier请求之后的请求，直到barrier请求完成。老的SCSI控制器/磁盘驱动器以及SATA磁盘驱动器属于这类设备。

iii.

对于设备队列深度为1的设备，这种设备相当于ii类设备的特例。只要保证分发的顺序就够了(保证i/o调度器不打乱顺序)。较老的SCSI控制器/磁盘驱动器和IDE驱动器属于这类设备。

2. 强制刷新数据到物理介质

使用I/O

barrier的原因主要是保护文件系统的完整性。意外掉电或者其他事件使得磁盘驱动器无法正常工作，将造成磁盘缓存中数据的丢失。所以，I/Obarrier需要保证i/o请求真正被顺序写入了非易失性介质上。

这儿有四种情况：

i.无write-back缓冲，保证请求自身的顺序就足够了。

ii.有write-back缓存但没有刷新缓存的操作。这种情况下，无法保证物理介质的写入顺序。这种类型的设备不能支持I/Obarrier。

iii.有write-bach缓存，有刷新缓存的操作但无FUA(forced unit

access)，这种情况下，我们需要两次缓存刷新操作：分别在barrier请求前后。

iv.有write-back缓存，刷新缓存操作和FUA。这是，我们只需要一次刷新操作来确保barrier请求之前的请求被写入物理介质。而barrier请求之后的刷新操作可以省略。因为我们可以指定barrier请求为FUA写，这样确保了barrier请求自身能被真正地写入物理介质。从而避免了第二次刷新。

怎样在驱动中支持barrier请求

---------------------------

所有barrier的处理都是在通用块层内部进行的。所有底层驱动需要实现自己的prepare_flush_fn函数，并且使用以下两个函数之一来说明自己支持哪种barrier类型以及怎样准备用于刷新缓存的请求。注意，“ordered”用来说明处理barrier请求的整个过程顺序，包括请求的分发和缓存的刷新。

typedef void (prepare_flush_fn)(struct request_queue *q, struct request *rq);

int blk_queue_ordered(struct request_queue *q, unsigned ordered,

prepare_flush_fn *prepare_flush_fn);

@q   : the queue in question

@ordered  : the ordered mode the driver/device supports

@prepare_flush_fn : this function should prepare @rq such that it

flushes cache to physical medium when executed

比如，SCSI磁盘驱动的prepare_flush_fn如下：

static void sd_prepare_flush(struct request_queue *q, struct request *rq)

{

memset(rq->cmd, 0, sizeof(rq->cmd));

rq->cmd_type = REQ_TYPE_BLOCK_PC;

rq->timeout = SD_TIMEOUT;

rq->cmd[0] = SYNCHRONIZE_CACHE;

rq->cmd_len = 10;

}

当前Linux中，支持以下7中顺序模式。以下表格显示了根据不同设备/驱动的特点需要采用哪种模式。在表格的最左边，QUEUE_ORDERED_前缀被省略了，以节约空间。

表格后面是各种模式的解释。注意，在QUEUE_ORDERED_DRAIN*中的描述使用了“=>”，而在QUEUE_ORDERED_TAG*的描述中使用了“->”。前者表示，前面的步骤必须在后面的步骤开始之前完成。而后者表示后面的步骤只要在前面步骤开始后就可以开始。

write-back cache ordered tag flush  FUA

-----------------------------------------------------------------------

NONE  yes/no  N/A  no  N/A

DRAIN  no  no  N/A  N/A

DRAIN_FLUSH yes  no  yes  no

DRAIN_FUA yes  no  yes  yes

TAG  no  yes  N/A  N/A

TAG_FLUSH yes  yes  yes  no

TAG_FUA  yes  yes  yes  yes

QUEUE_ORDERED_NONE

I/O barrier不需要或者不被支持

Sequence: N/A

QUEUE_ORDERED_DRAIN

请求以请求队列中分发的顺序进行排序，不需要刷新缓存操作。

Sequence: drain => barrier

QUEUE_ORDERED_DRAIN_FLUSH

请求以请求队列中分发的顺序进行排序，需要在barrier请求前和之后刷新缓存。

Sequence: drain => preflush => barrier => postflush

QUEUE_ORDERED_DRAIN_FUA

请求以请求队列中分发的顺序进行排序，之需要在barrier请求前刷新缓存。在barrier请求上使用FUA，省略barrier请求之后的刷新。

Sequence: drain => preflush => barrier

QUEUE_ORDERED_TAG

请求被ordered tag排序，不需要刷新缓存。

Sequence: barrier

QUEUE_ORDERED_TAG_FLUSH

请求被ordered tag排序，在barrier请求之前和之后，需要刷新缓存。

Sequence: preflush -> barrier -> postflush

QUEUE_ORDERED_TAG_FUA

请求被ordered

tag排序，在barrier请求之前需要刷新缓存。在barrier请求上使用FUA，省略barrier请求之后的刷新。

Sequence: preflush -> barrier

----------------

*SCSI层当前不能使用TAG ordering，即使磁盘驱动器，控制器和驱动支持这个特性。其主要原因是SCSI中间层的请求分发函数不是原子的。在分发请求时，它会释放请求队列的锁，转而获取SCSI host的锁。这样，就可能发生请求相对位置改变的情况。一但这个问题解决了，TAG ordering将会启用。

*当前，无论那种顺序模式被使用，某一时刻，只能有一个barrier请求被处理。所有I/O barrier都会被通用块层扣留起来，直到前面的I/O barrier处理完成。这和DRAIN顺序的设备没有什么不同。但是，对于TAG 顺序的设备，由于其命令时延较长，如果I/O barrier分发频

繁，传递多个I/O barrier到底层可能会有帮助。

*完成顺序。顺序的请求被顺序的分发，但不要求顺序完成。Barrier实现可以处理乱序完成的请求。也就是说，请求必须被顺序处理，但是硬件/软件完成路径允许以乱序进行通知。比如，当前SCSI中间层就没在错误处理时预设完成顺序。

*重新入队顺序。底层驱动可以自由重新入队任何请求。由于barrier序列在重新入队时必须保持顺序，通用电梯程序中保证插入的请求符合barrier顺序。参见blk_ordered_req_seq() 和 ELEVATOR_INSERT_REQUEUE handling in __elv_add_request()。

注意，在完成一个顺序序列后面的请求时，块设备不能重新入队之前的请求。当前，没有针对这种错误的检查。

*错误处理。当前，当在一个顺序序列中的请求发生错误时，通用块层会把错误报告给上层。不幸的是，这样做往往还不够。比如有如下的请求，使用QUEUE_ORDERED_TAG_FLUSH顺序模式。

[0] [1] [2] [3] [pre] [barrier] [post] < [4] [5] [6] ... >

still in elevator

假设[2],[3]是用来更新文件系统metadata的写请求(日志等)。[barrier]用来标识这些更新是有效的。考虑以下序列：

i.请求[0]~[post] 离开了请求队列，进入底层驱动。

ii. 过了一会儿，不幸发生了，磁盘驱动器出现故障，[2]失败。注意，此时[0],[1],和[3]都已经完成了。但是[pre]还没有完成，因为磁盘驱动器必须按照顺序来处理它。它在也会失败。

iii.此时，错误处理介入。它确定错误不能恢复，[2]操作失败，并重启操作。

iv.[pre][barrier][post]得到处理

v.掉电

问题在于，barrier请求本来认为文件系统更新请求[2]和[3]会被安全地写入物理介质。如果机器在barrier被写入后crash掉。文件系统的恢复代码可以依靠它。不幸的是，这种情况不再成立。也就是说，I/O barrier的成功，必须依赖前面某些请求的成功，这究竟是那些请求，只有上面的文件系统才知道。

要解决这个问题，可以通过实现一种方式，来告诉通用块层哪些请求影响之后的barrier请求，使底层驱动只有在得到通用块层通知后才进行错误处理。