"For the purposes of this discussion, it may be helpful to refer
to your editor's bad artwork, as seen on the right, for a
simplistic look at how block I/O happens in a Linux system. At the
top, we have several sources of I/O activity. Some requests come
from the virtual memory layer, which is cleaning out dirty pages
and trying to make room for new allocations. Others come from
filesystem code, and others yet will originate directly from user
space. It's worth noting that only user-space requests are handled
in the context of the originating process; that creates
complications that we'll get back to. Regardless of the source, I/O
requests eventually find themselves at the block layer, represented
by the large blue box in the diagram.
"Within the block layer, I/O requests may first be handled by
one or more virtual block drivers. These include the device mapper
code, the MD RAID layer, etc. Eventually a (perhaps modified)
request heads toward a physical device, but first it goes into the
I/O scheduler, which tries to optimize I/O activity according to a
policy of its own. The I/O scheduler works to minimize seeks on
rotating storage, but it may also implement I/O priorities or other
policy-related features. When it deems that the time is right, the
I/O scheduler passes requests to the physical block driver, which
eventually causes them to be executed by the hardware."
