또한 이 책에서 제시한 다른 가상 장치와 마찬가지로 sbull 장치는 내부 구조로 설명됩니다: 각 구조체 요청 구조는 I/O 블록 요청이지만 더 높은 수준의 독립적인 요청을 결합하여 제공될 수 있습니다. 요청에 대해 전송할 섹터는 주 메모리에 분산될 수 있지만 항상 장치의 연속 섹터 집합에 해당합니다. 요청은 일련의 세그먼트로 표시되며 각 세그먼트는 메모리의 버퍼에 해당합니다. 커널은 인접 섹터를 참조하지만 쓰기 요청을 읽기 요청과 결합하지 않는 요청을 단일 구조체 요청 구조로 결합할 수 있습니다. 이 장치에 대한 I/O 요청을 관리하기 위해 커널에서 사용하는 구조; 16.3절에서 살펴보겠습니다. LDDv3 예제를 코드의 기초로 사용한 작고 간단한 블록 장치가 있습니다. 그러나 새 API로 작업하기 위해 변경해야 할 것을 파악하는 데 어려움을 겪고 있습니다. 이 섹션에서는 고급 드라이버가 관심을 가질 만한 블록 계층의 몇 가지 다른 측면을 다룹니다. 다음 시설 중 어느 것도 올바른 드라이버를 작성하는 데 사용할 필요가 없지만 경우에 따라 도움이 될 수 있습니다. 블록 레이어의 디자인 대부분은 성능에 중점을 두고 있습니다. 많은 char 장치가 최대 속도 이하로 실행될 수 있으며 시스템 전체의 성능에는 영향을 미치지 않습니다. 그러나 블록 I/O 하위 시스템이 잘 조정되지 않으면 시스템이 잘 실행되지 않습니다. Linux 블록 드라이버 인터페이스를 사용하면 블록 장치를 최대한 사용할 수 있지만 반드시 처리해야 하는 복잡성을 부과할 수 있습니다.

다행히도, 2.6 블록 인터페이스는 이전 커널에서 발견 된 것에 비해 훨씬 향상되었습니다. 2.6 블록 계층은 장벽 요청의 개념으로 이 문제를 해결합니다. 요청이 REQ_HARDBARRER 플래그로 표시되어 있으면 다음 요청을 시작하기 전에 드라이브에 기록해야 합니다. “드라이브에 기록”을 통해 데이터가 실제로 상주하고 물리적 미디어에 지속되어야 한다는 의미입니다. 많은 드라이브에서 쓰기 요청의 캐싱을 수행합니다. 이 캐싱은 성능을 향상하지만 장벽 요청의 목적을 무효화할 수 있습니다. 중요한 데이터가 여전히 드라이브의 캐시에 있을 때 정전이 발생하면 드라이브가 완료를 보고한 경우에도 해당 데이터가 손실됩니다.