轉載博客：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