我什么时候应该在内核blockDev驱动程序中使用req_op_flush？ （Req_op_flush Bio＆＃x27; flush Dirty Raid Controller Caches吗？）

Question

我什么时候应该在内核blockDev驱动程序中使用req_op_flush，并且接收req_op_flush（或同等的SCSI CMD）的硬件的预期行为是什么？

在Linux内核中，当A struct Bio标记为req_op_flush以写入式控制器的形式传递给RAID Controller卷时，RAID控制器是否应该冲洗其肮脏的缓存器？

在我看来，这是req_op_flush的目的，但这与想要快速使用写入返回的情况是不符的：如果缓存是电池收益的，是否应该忽略控制器吗？

在 ext4的super.c ext4 /a>，写入blkdev_issue_flush（）通过barrier = 0安装选项禁用障碍时。这似乎暗示着RAID控制器被告知要加快了缓存...但是RAID固件是否会违反规则？

• 冲洗行为是否取决于固件实施和制造商？
• SAS/SCSI规范在哪里？
• 其他考虑？

Answer 1

Linux-Block邮寄清单上的Christoph Hellwig说：

电源故障的设备
保护会宣传（例如，在NVME中使用VWC标志），[Linux内核]永远不会发送冲洗。

Kernel.org的Keith Busch：

您可以检查队列属性，/sys/block/＆lt; disk＆gt;/queue/write_cache。如果是
值是“通过”，然后设备报告没有一个
挥发性缓存。如果是“写回”，则具有挥发性的缓存。

如果这听起来很后退，请考虑使用突袭
控制器缓存为示例：

1. a RAID控制器，带有 non-dolaTile “ writeback”缓存（从
   控制器的观点，即带有电池的）是“通过”
   就内核而言，设备是因为控制器将
   在持续的缓存中，将写入作为完整的写入。

   
   

2. 具有 domaidile “写下”缓存的RAID控制器（来自
   控制器的观点，即没有电池的）是“写回”
   就内核而言，设备是因为控制器将
   在缓存中返回写入的文字，但
   缓存不是持久的！因此，在这种情况下，需要冲洗/FUA。

   
   

[参考：https://lore.kernel.org/all/< 8DDF8C88A98C9E818C8C8C9BC7878C9D“> [email＆nbsp; procepted] < /a>/]

从个人经验中，并非所有RAID控制器都将正确设置Queue/write_cache，如上述Keith所示。如果您知道自己的数组具有以写入模式运行的非易失性高速缓存，请确保它在“写”中，以便将冲洗液被删除：

]# cat /sys/block/<disk>/queue/write_cache
<cache status>

如果不处于适当的模式，则将其修复。下面的这些设置似乎反映了，但是如果它们这样做，则在上面重新阅读＃1和＃2，因为这些是正确的：

如果您有非挥发性cache （ IE，带有 bbu）：

]# echo "write through" > /sys/block/<disk>/queue/write_cache

如果您有一个挥发性缓存（即，没有 bbu）：

]# echo "write back" > /sys/block/<disk>/queue/write_cache

因此，关于何时标记的问题的答案req_op_flush在您的内核代码中是：每当您认为代码应将磁盘提交时。由于块层可以重新订购任何bio请求，

1. 请发送写入io，等待其完成
2. 发送齐平，等待齐平完成

，然后保证您将在磁盘上的＃1中获得IO 。

但是，如果所编写的设备在“通过”模式中具有CACHE_MODE，则齐平将立即完成，即使在功率损失后，它都可以完成工作并保持非挥发性高速缓存（BBU，supercap之后） ，flashcache等）。