scheduling/merging on top of a DM target?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We’re emulating some in-disk algorithms in a device mapper target, and would like to be able to do a fair comparison between the emulated and real versions; however they see radically different I/O streams, evidently because there’s no scheduling / request merging / etc. on top of the bio-based device mapper target.

It appears that if our device mapper were request-based instead of bio-based we wouldn’t have this issue, but after reading a bunch of history on the mailing list archives I don’t think this is going to happen easily.

Does anyone have any thoughts on quick-and-dirty ways to approximate this so we can get some preliminary measurements? dm-multipath won’t stack on a bio-based target, and attempts to stack loopback and various iscsi targets on top haven’t achieved the desired results. (in general these have resulted in our dm target seeing individual 4K I/Os, instead of the larger I/Os at the higher layer)

Thanks,
.....................................................................
 Peter Desnoyers                                  pjd@xxxxxxxxxxx
 Northeastern Computer & Information Science


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux