Description
part_block allows for accessing each partition on a block-provider, normally a block device, individually. It sits in-between the block-provider component and the components requiring access, e.g. the file-system provider. Each client gets its own Block session covering the range of blocks belonging to the particular partition while part_block establishes one session to interact with the provider component itself that covers the whole range of blocks.
Structuring it in this way separates all participants but at the same time results in having to deal with the payload twice because two Packetstreams are involved on the I/O path. Depending on the use-case at hand that binds resources, i.e. CPU cycles, that could be spend on other tasks.
Following the example of the chroot component, which mediates the File_system session access, combined with the recent change of limiting the scope via the File_system session's label, could also pave the way for turning part_block around in a comparable fashion.
Annotating the Block session with a start offset and range of blocks (or similar information) covered by the session arguments would allow for selecting a specific portion of the block-provider and by allowing the client to open the session directly at the source one hop in the I/O path could be spared. As a side-effect the settings of each session can be tailored more closely to each particular use-case.
As a down-side this pushes more complexity into the block-provider and depending on the driver the benefits might be limited (in case where there is only one useable queue with a more constrainted number of requests) and softens the separation.