Linux IO barrier

转载博客：https://blog.csdn.net/younger_china/article/details/51138375

I/O顺序问题是一个比较综合的问题，它涉及的层次比较多，从VFS page cache到I/O调度算法，从IO子系统到存储外设。而Linux I/O barrier就是其中重要的一部分。

可能很多人认为，在做了文件写操作后，调用fsycn就能保证数据可靠地写入磁盘。大多数情况下，确实如此。但是，由于缓存的存在，fsycn这些同步操作，并不能保证存储设备把数据写入非易失性介质。如果此时存储设备发生掉电或者硬件错误，此时存储缓存中的数据将会丢失。这对于像日志文件系统中的日志这样的数据，其后果可能是非常严重的。因为日志文件系统中，数据的写入和日志的写入存在先后顺序。如果顺序发生错乱，则可能破坏文件系统。因此必须要有一种方式，来知道写入的数据是否真的被写入到外部存储的非易失性介质，比便文件系统根据写入情况来进行下一步的操作。

如果把fsycn理解成OS级别同步的话，那么对于Barrier I/O，我的理解就是硬件级别的同步。

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

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

1.请求顺序
非barrier请求不能跨越barrier请求。barrier请求之前的请求必须先于barrier请求进行处理，barrier请求之后的请求必须在barrier请求完成后进行处理。
根据磁盘驱动器的特性，以上条件可以用以下三种方式来实现：

(1)对于设备队列深度大于1（TCQ设备）并且支持ordered tag的设备，块设备层只需要发送一个标为ordered的请求来作为barrier，底层驱动，控制器和磁盘驱动器负责确保请求的顺序。现在，大多数SCSI控制器/磁盘驱动器都应该支持这个特性。

(2)对于设备队列深度大于1但是不支持ordered tag的设备，块设备层确保barrier请求往设备分发前，之前的请求将先被处理完。块设备层也会延迟barrier请求之后的请求，直到barrier请求完成。老的SCSI控制器/磁盘驱动器以及SATA磁盘驱动器属于这类设备。

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

2. 强制刷新数据到物理介质
使用I/O barrier的原因主要是保护文件系统的完整性。意外掉电或者其他事件使得磁盘驱动器无法正常工作，将造成磁盘缓存中数据的丢失。所以，I/Obarrier需要保证i/o请求真正被顺序写入了非易失性介质上。
这儿有四种情况：

(1)无write-back缓冲，保证请求自身的顺序就足够了。
(2)有write-back缓存但没有刷新缓存的操作。这种情况下，无法保证物理介质的写入顺序。这种类型的设备不能支持I/O barrier。
(3)有write-back缓存，有刷新缓存的操作但无FUA(forced unit access)，这种情况下，我们需要两次缓存刷新操作：分别在barrier请求前后。
(4)有write-back缓存，刷新缓存操作和FUA。这是，我们只需要一次刷新操作来确保barrier请求之前的请求被写入物理介质。而barrier请求之后的刷新操作可以省略。因为我们可以指定barrier请求为FUA写，这样确保了barrier请求自身能被真正地写入物理介质。从而避免了第二次刷新。

参考博客：
https://blog.csdn.net/jemmy858585/article/details/43935219
https://blog.csdn.net/younger_china/article/details/51138375