Recent work on file systems and Linux block devices requires a deeper understanding of the relationship and interaction between the file system and the underlying block device. I refer to the book has Aoqingyun "Storage technology principle analysis-based on the Linux2.6 kernel code", while reference is also Jonathancorbet, Alessandrorubini and Gregkroah-hartman A classic book on Linux devices, "Linux device driver Edition3", Chen Cossong, "Deep Linux device driver kernel mechanism". A comparison, or Aoqingyun writing is very much more tightly stored. On the whole, "analysis of the principle of storage technology-based on the Linux2.6 kernel code" in the hierarchical division of the block device is clear, a complete summary of the common block layer, IO scheduling layer and the physical block device layer between the association. Here's how he divides the block device drivers:
650) this.width=650; "src=" Https://s1.51cto.com/wyfs02/M02/92/D0/wKioL1kDLaqjFHt_AAC07xVhoXw855.png "title=" Ao_ Block_device_layer.png "alt=" Wkiol1kdlaqjfht_aac07xvhoxw855.png "/>
But for its hierarchical division of block device drivers, the figure above is not particularly accurate. For example, depending on the description in Linuxstorage Stack DIAGRM, the MD and devicemapper device drivers should be above the I/O Scheduler:
650) this.width=650; "src=" Https://s4.51cto.com/wyfs02/M00/92/D2/wKiom1kDLdTDqn29AAHYNsWxOPA863.png "title=" My_ Block_device_understanding.png "alt=" Wkiom1kdldtdqn29aahynswxopa863.png "/>
Because Ioscheduler to implement scatter Read/gather write, it must be based on the physical characteristics of the storage platter or RAID, based on the logic IO request from the upper logical block device or devicemapper. Translates it into an IO request on the corresponding storage device. So this level of devicemapper needs to be above the IOSCHEDULRE layer.
This article from "Storage Chef" blog, reproduced please contact the author!
"Dive into one of the Linux block device driver hierarchies" overall level