多路径下实现i/o顺序很难

突然想明白，其实要在多路径下实现i/o顺序很难。
因为顺序i/o的发起者是文件系统，一般式文件系统的日志模块。在文件系统和多路径驱动之间往往会有一层volume manager。volume manager可能会把文件系统i/o分散到多个设备，而每个设备又可能存在多个路径。
假设文件系统写了数据块b1,b2,b3，然后提交日志l1。如果volume manager做了条带化，b1, b2,b3可能被分发到两个设备。这儿假设volume manager能识别设备多路径，b1 被分发到lun1, b2,b3被分发到lun2。而由于每个lun存在多路径，b2,b3被分发都lun2所对应的两条路径上，比如/dev/sda和/dev/sdb. 现在，3个块都到了OS的设备队列。此时，commit 日志l1, 假设文件系统发送了一个barrier i/o，使得b1,b2,b3，l1顺序写入设备。这下问题来，通用块层处理barrier i/o时，根本无法保证b2,b3的顺序，因为其在两个OS device。再上一层，dmp层，它不能保证b1和b2,b3的顺序。因为b1和b2,b3在不同的lun。因此，只有volume manager才可能了解所有i/o的走向。所以，要保证i/o顺序，需要volume manager能理解多路径，并能协调各lun和每个lun上的多路径的io顺序。感觉要实现起来很难。不知道现在的日志文件系统是否能运行在支持多路径的volume manager上。前段时间，在maillist看到xfs在device mapper multipath 块设备上，再提交日志时会有警告。主要是因为其日志的barrier i/o无法得到multipath driver的正确处理。如果再加上一个volume manager，估计更不能处理了。但是提说Veritas的volume manager和dmp driver能解决这个问题。

 

一下实验证明device mapper不能实现barrier i/o。

在多路径设备上创建reiserfs，然后用barrier=flush参数mount reiserfs。

在mount时，reiserfs会读super block。读取superblock时，通过submit_barrier_buffer调用 submit_bh(WRITE_BARRIER, bh)向块设备发送barrier i/o。

但是在dm的make_request_fn（dm_request）中，device mapper的request_queue并没有申明支持barrier：QUEUE_ORDERED_NONE.所以，submit_bh的返回结果是EOPNOTSUPP.从而，reiserfs调用disable_barrier来禁用barrier flush。